Datenverwaltungssystem, das einen Datenthesaurus zur Abbildung zwischen mehreren Datenschemata oder

专利摘要:
In einer Ausführungsform ist ein System zum Verwalten eines zentral verwalteten Masterspeichers für einem Unternehmen zugeordnete Kernunternehmensreferenzdaten vorgesehen. Ein zentraler Masterspeicher enthält die Referenzdaten, wobei die Referenzdaten einer Vielzahl von Schemata zugeordnet sind, wobei jedes Schema ein oder mehrere Datenmodelle für Referenzdaten enthält, wobei jedes Datenmodell eines oder mehrere Felder enthält. Eine mit dem Speicher verbundene Datenverwaltungsdienststruktur stellt Dienste zum Verwalten der Referenzdaten im Speicher bereit. Die Dienststruktur unterstützt ein Masterschema, das eine Vereinigung einer Vielzahl von Modellen und entsprechenden Feldern in der Vielzahl von Schemata enthält. Die Dienststruktur unterstützt auch einen Thesaurus, der für jedes Feld im Masterschema einen Satz von Synonymen enthält, von denen jedes eine Abbildung zwischen dem Feld im Masterschema und einem entsprechenden Feld in einem bestimmten der Vielzahl von Schemata repräsentiert. Das Masterschema und der Thesaurus ermöglichen eine zentrale Verwaltung der Referenzdaten im Speicher über eine Vielzahl heterogener externer operativer Systeme hinweg, die unterschiedliche zugeordnete Datenmodelle haben und zur operativen Verwendung der Referenzdaten gemäß zugeordneter Geschäftsarbeitsabläufe einen indirekten Zugriff auf die Referenzdaten im Speicher haben.
公开号:DE102004022481A1
申请号:DE102004022481
申请日:2004-05-07
公开日:2005-01-13
发明作者:Pallab K. Plano Chatterjee；Vasudev Arlington Rangadass
申请人:I2 Technologies Inc；
IPC主号:G06Q10-00

专利说明:
[0001] DieErfindung bezieht sich allgemein auf die Datenverwaltung und insbesondereauf ein Datenverwaltungssystem, das einen Datenthesaurus zur Abbildungzwischen mehreren Datenschemata oder zwischen mehreren Domänen innerhalbeines Datenschemas bereitstellt.
[0002] Eskann sein, dass ein Unternehmen ein Masterdatenverwaltungssystemfür dieDurchführung einerVerwaltung von Unternehmensdaten verwendet. Um ein Unternehmen angemessenzu definieren, werden beträchtlicheDatenmengen benötigt. DieDaten könnenzwei grundsätzlichenTypen angehören.Ein erster Datentyp, der als Kernunternehmensreferenzdaten bezeichnetwerden kann, beschreibt die Struktur und die Charakteristik desUnternehmens und seiner Entitätenund hat keinen vorübergehendenoder transaktionalen Charakter. Dieser Datentyp kann einem Unternehmensdatenmaster zugeordnetwerden und kann in einem Kernreferenzdatenspeicher gespeichert werden,auch wenn solche Daten nicht auf den Datentyp eingeschränkt sind, derherkömmlichenUnternehmensdatenmasters zugeordnet ist. Dabei ist die effizienteHandhabung der Daten entscheidend, genauso wie die ordentliche undprozessgestezerte Verwaltung des Zustands der Daten. Die Verwendungdieser Daten ist im Allgemeinen nicht auf bestimmte Teile des Unternehmenseingeschränkt;diese Daten werden vielmehr typischerweise das ganze Unternehmendurchdringend und zusammen mit seinen Wertkettenpartnern verwendet.Der zweite Datentyp, der als operative Daten bezeichnet werden kann,besteht aus vorübergehenden Transaktionsdaten,die von Planungs-, Ausführungs-, Überwachungs-oder anderen Unternehmenslösungskomponentenbenötigtwerden. Dieser Datentyp wird typischerweise nicht im Kernreferenzdatenspeichergespeichert; das Masterdatenverwaltungssystem stellt eine Aufbereitungs-und Verteilungsstruktur fürdiese Daten bereit. Ein bei vielen Unternehmen auftretendes Problemist die Schaffung eines Systems zur effektiven und skalierbarenVerwaltung, Verteilung und Verwendung sowohl seiner Kernunternehmensreferenzdatenals auch seiner Transaktionsdaten in einer Weise, welche den Bedarf nachdiesen Daten innerhalb des Unternehmens als Ganzes und auch denspezifischen Bedarf der Planungs-, Durchführungs-, Überwachungs- und anderer Unternehmenslösungskomponenten,die dem Unternehmen zugeordnet sind, unterstützt.
[0003] Ineiner Ausführungsformwird ein System zum Verwalten eines zentral verwalteten Masterspeichersfür Kernunternehmensreferenzdaten,die einem Unternehmen zugeordnet sind, bereitgestellt. Ein zentralerMasterspeicher enthältdie Kernunternehmensreferenzdaten, wobei die Kernunternehmensreferenzdatenmit mehreren Datenschemata verknüpftsind, wobei jedes Datenschema eines oder mehrere Datenmodelle für Kernunternehmensreferenzdatenenthält,wobei jedes Datenmodell ein oder mehrere Felder enthält. Einemit dem zentralen Masterspeicher verbundene Datenverwaltungsdienststrukturstellt Dienste zur Verwaltung der Kernunternehmensreferenzdatenim zentralen Masterspeicher bereit. Die Dienststruktur unterstützt einMasterdatenschema, das eine Vereinigung der mehreren Datenmodelleund zugeordneten Felder in den mehreren Datenschemata enthält. DieDienststruktur unterstütztauch einen Datenthesaurus, der fürjedes Feld im Masterdatenschema einen Satz von Feldsynonymen enthält, vondenen jedes eine Abbildung zwischen dem Feld im Masterdatenschemaund einem entsprechenden Feld in einem Bestimmten der mehreren Datenschematarepräsentiert.Das Masterdatenschema und der Datenthesaurus ermöglichen eine zentrale Verwaltungder Kernunternehmensreferenzdaten im zentralen Masterspeicher über eine Vielzahlheterogener externer operativer Systeme hinweg, die unterschiedlichezugeordnete Datenmodelle haben und einen indirekten Zugang zu den Kernunternehmensreferenzdatenim zentralen Masterspeicher zur operativen Verwendung der Kernunternehmensreferenzdatengemäß zugeordneterGeschäftsarbeitsabläufe haben.
[0004] BestimmteAusführungsformender vorliegenden Erfindung könneneinen oder mehrere technische Vorteile bieten. Zum Beispiel können bestimmteAusführungsformeneine Unternehmensstruktur vorsehen, die eine Klassifikation in Konfigurations-,Planungs-, Ausführungs-und Überwachungssegmenteenthält.Bestimmte Ausführungsformenkönnenein sicheres Aufzeichnungssystem vorsehen, dessen Architektur undAufbau fürdie Verwaltung von Kernunternehmensreferenzdaten optimiert ist.Bestimmte Ausführungsformenkönneneine vollständigeoder teilweise Automation wichtiger zeit- und arbeitsintensiverGeschäftsvorgänge gemäß eingebetteterGeschäftsabläufe aufUnternehmensebene ermöglichen.Bestimmte Ausführungsformenkönneneinen oder mehrere Thesauren zur Abbildung zwischen mehreren Datenschemataoder zwischen mehreren Domäneninnerhalb eines Datenschemas unterstützen. Bestimmte Ausführungsformender vorliegenden Erfindung könnenalle, einen Teil oder keinen dieser technischen Vorteile vorsehen.Bestimmte Ausführungsformenkönneneinen oder mehrere weitere technische Vorteile bieten, von deneneiner oder mehrere dem Fachmann aus den hier vorgelegten Figuren,der Beschreibung und den Ansprüchenersichtlich sind.
[0005] Umein vollständigeresVerständnisder vorliegenden Erfindung und deren Merkmale und Vorteile zu ermöglichen,wird auf die folgende Beschreibung in Verbindung mit den beiliegendenZeichnungen Bezug genommen. Es zeigt:
[0006] 1 eine Beispielunternehmensanwendungsstrukturmit einem Masterdatenverwaltungs(MDM)-System;
[0007] 2 ein Beispiel einer logischenGeschäftsarchitekturfür einMDM-System;
[0008] 3 ein Beispiel einer logischentechnischen Architektur fürein MDM-System;
[0009] 4 ein Beispiel für eine logischeDatendienstarchitektur fürein MDM-System;
[0010] 5 ein Beispiel für eine logischeArchitektur einer MDM-Datenbank;
[0011] 6 ein Beispiel für eine Architekturzur gemeinsamen Informationsnutzung für ein MDM-System;
[0012] 7 ein Beispiel für ein MDM-Studiound eine zugeordnete MDM-Modellbibliothek;
[0013] 8 ein Beispiel von Schematafür ineinem MDM-System gespeicherte Referenzdaten;
[0014] 9A und 9B Beispielverfahren zum Erweitern einesReferenzdatenmodells innerhalb eines MDM-Systems;
[0015] 10 Beispiele von Datenlexikafür Schematainnerhalb eines MDM-Systems;
[0016] 11 Beispieldomänen für Schematainnerhalb eines MDM-Systems;
[0017] 12 ein Beispiel für einenDatenthesaurus, der Abbildungen und entsprechende Synonyme über eineMehrzahl von Schemata innerhalb eines MDM-Systems hinweg vorsieht;
[0018] 13 ein Beispiel für einenDatenthesaurus, der Abbildungen und entsprechende Synonyme über eineVielzahl von Domäneninnerhalb eines Schemas innerhalb eines MDM-Systems hinweg vorsieht;
[0019] 14 ein Beispiel-MDM-Nutzungsmodell;
[0020] 15 ein Beispiel einer logischenphysischen Architektur fürein MDM-System; und
[0021] 16 ein Beispiel für einenVorgang zur Einführungeines neuen Artikels, der innerhalb eines MDM-Systems vorgesehenist.
[0022] 1 veranschaulicht ein Beispieleiner Unternehmenslösungsstruktur 2,die ein MDM-System 4 enthält. In einer Ausführungsformenthältdie Struktur 2 eine Klassifikation eines zugeordneten Unternehmensin vier grundlegende Segmente: (1) Konfiguration des Unternehmensund seiner Entitäten;(2) Planung bezüglichdes Unternehmens und seiner Entitäten; das heißt Entscheidungendarüber,was zu tun ist; (3) Durchführungbezüglichdes Unternehmens und seiner Entitäten; das heißt, Handelnnach diesen Entscheidungen; und (4) Überwachung bezüglich desUnternehmens und seiner Entitäten;das heißt Überwachender Ergebnisse dieser Entscheidungen und das Liefern einer entsprechendenRückmeldung andie Konfigurations- und Planungssegmente. In dieser Ausführungsformrepräsentiertdas MDM-System 4 das Konfigurationssegment, während diePlanungs-, Durchführungs-und Überwachungs-Unternehmenslösungskomponenten 6 dasPlanungs-, das Durchführungs-bzw. das Überwachungssegmentrepräsentieren.
[0023] DasMDM-System 4 leistet eine zentralisierte Speicherung undVerwaltung von Unternehmensreferenzdaten, eine Pflege der Referenzdatenund zugeordnete Datenverwaltungsvorgänge, die von Unternehmenslösungskomponenten 6 undzugeordneten operativen Vorgängengetrennt sind, währenddie Referenzdaten den Unternehmenslösungskomponenten 6 nachBedarf zum Verbrauch zur Verfügung gestelltwerden. Eine zentrale Speicherung und Verwaltung von Referenzdatenfür bestehendeund zukünftigeUnternehmenslösungskomponenten 6 kann eineErweiterung oder andere Modifikation der Unternehmenslösungskomponenten 6 ermöglichen,ohne dass dazu die Referenzdaten innerhalb des MDM-Systems 4 modifiziertzu werden brauchen. Eine zentrale Speicherung und Verwaltung derReferenzdaten kann auch eine Integration von Unternehmenslösungskomponenten 6 erleichtern,zum Beispiel dann, wenn eine Unternehmenslösungskomponente 6 durcheine andere ersetzt wird oder eine Unternehmenslösungskomponente eingeführt wird,die eine vollständigneue Geschäftsfunktionvorsieht. Eine zentrale Speicherung und Verwaltung von Referenzdatenkann außerdemeine Integration eines Unternehmens in ein anderes, zum Beispielim Zusammenhang mit einer Fusion oder einer Übernahme, ermöglichen.Gegebenenfalls kann in bestimmten Ausführungsformen das MDM-System 4 alsReferenzdatenverwaltungs-, Masterdatenverwaltungs- oder ein andereszentrales Datenverwaltungssystem bezeichnet werden.
[0024] Infrastrukturdienste 8 seheneine Massendatenübertragungund eine Unternehmensnachrichtenübermittlungzwischen MDM- und Unternehmenslösungskomponenten 6 gemäß Geschäftsarbeitsabläufen vor,die im Zusammenhang mit den Infrastrukturdiensten 8 betriebenwerden. Diese Arbeitsabläufe,die teilweise in das MDM- System 4 undteilweise in die Infrastrukturdienste 8 eingebettet seinkönnen, können speziellangepasste optimale Geschäftsverfahrendes Unternehmens beinhalten. Zusätzlich können dieseArbeitsabläufeunter der Verwendung einer "Arbeitsablaufinaschine" (Workflow Engine)auf der Ebene des Unternehmens und entsprechender MDM-Ressourcen, die derWorkflow Engine zur Verfügungstehen, ganz oder teilweise automatisiert werden.
[0025] Ineiner Ausführungsformkann das MDM-System 4 einen oder mehrere Thesauren zur Abbildungzwischen mehreren Datenschemata oder zwischen mehreren Domänen innerhalbeines Datenschemas unterstützen.Auch wenn diese Thesauren vorteilhafterweise im Zusammenhang mitdem MDM-System 4 eingesetzt werden können, wird bei der vorliegendenErfindung die Verwendung solcher Thesauren in einem beliebigen geeignetenDatenverwaltungszusammenhang in Betracht gezogen.
[0026] 2 veranschaulicht ein Beispielfür eine logischeGeschäftsarchitektur 10 für ein MDM-System 4.Allgemein stellt die logische Geschäftsarchitektur eine geschäftszentrischeSicht eines MDM-Systems 4 dar und enthält Kerngeschäftsvorgänge, Diensteund Datenelemente, die das MDM-System 4 je nach dem Charakterdes dem MDM-System 4 zugeordneten Unternehmens möglicherweisebereitstellen muss. In einer Ausführungsform enthält das MDM-System 4 eineProzessschicht 12, die einen Kontext zur Implementierungund zur ganzen oder teilweisen Automatisierung von Geschäftskonfigurationsprozessen 14 liefert.Eine Dienstschicht 16, die unter der Prozess-schicht 12 liegt,liefert Dienste 18, die Funktionen bereitstellen, welcheProzessaufgaben ermöglichen,die fürdie Prozesse 14 geeignet sind. Eine Datenschicht 20,die unter der Dienstschicht 16 liegt, liefert Basisdatenmodelleund physische Repräsentationenzum Speichern von Kernunternehmensreferenzdaten 22, um sieim Zusammenhang mit den Prozessen 14 und ihren zugeordnetenDiensten 18 abzurufen und zu verwenden.
[0027] EinVerständnisder grundlegenden Konzepte im Zusammenhang mit den Zwecken und Funktionendes MDM-Systems 4 kann beim Verständnis der MDM-Architektur helfen.Im Kern des MDM-Systems 4 liegt das Konzept der Datenverwaltung,das sowohl umfasst, welche Daten gespeichert werden, als auch, wiediese Daten gespeichert und zur Verfügung gestellt werden. Da dasMDM-System 4 hauptsächlichauf Strukturdaten bezogen ist, welche das Unternehmen beschreibenoder genauer auf Daten, die Entitäten innerhalb der Geschäftsstrukturdes Unternehmens zugeordnet sind, liegt der Schwerpunkt der MDM-Architektur auf derSpeicherung, der Verwaltung und dem Abrufen von Daten, die Entitäten oder Beziehungenzwischen den Entitätenzugeordnet sind. In einer Ausführungsformstellt das MDM-System 4 einen solchen Datenspeicher, eineentsprechende Datenverwaltung und ein entsprechendes Datenabrufenunter der Verwendung des Kern-MDM-Referenzdatenspeichers auf derGrundlage eines mehrdimensionalen Datenbankkonstrukts bereit.
[0028] Nunsoll das folgende Beispiel betrachtet werden. Ein Beispiel einerEntitätim Zusammenhang mit einem Einzelhandelsunternehmen ist ein Artikel. ArtikelkönnenAttribute wie die Größe, dasGewicht, die Farbe usw. haben. Wenn eine bestimmte Entität, in diesemZusammenhang ein bestimmter Artikel, als eine Koordinate in einerersten, Artikel repräsentierendenDimension betrachtet wird, dann sind die Attribute der bestimmtenArtikelentitätder Koordinate fürden bestimmten Artikel in der Artikeldimension zugeordnet. An diesemPunkt hat man es bei diesem Beispiel mit nur einem eindimensionalenGeradenraum zu tun, in dem diskrete Punkte auf der Geraden bestimmteArtikel repräsentieren.
[0029] Einweiteres Beispiel einer einem Unternehmen zugeordneten Entität ist einLaden oder ein anderer Standort. Standorte können Attribute wie zum Beispieldie Größe, diephysische Adresse usw. haben. Wie der oben erörterte bestimmte Artikel kann einbestimmter Standort als eine Koordinate in einer Standorte repräsentierenden,zweiten Dimension betrachtet werden, wobei die Attribute der bestimmten Standortsentität der Koordinatefür denbestimmten Standort in der Standortdimension zugeordnet sind. Andiesem Punkt hat man es bei dem Beispiel mit zwei eindimensionalenGeradenräumenzu tun, wobei diskrete Punkte auf der ersten Geraden bestimmte Artikelund diskrete Punkte auf der zweiten Geraden bestimmte Standorterepräsentieren.Das Beispiel kann erweitert werden, so dass Attribute eingeschlossenwerden, die von der Kombination eines bestimmten Artikels und einesbestimmten Standorts abhängen.Weder die Artikeldimension noch die Standortsdimension allein reichendann zum Speichern solcher mehrdimensionaler Attribute aus. Wennjedoch die Artikel- und die Standortsdimension als Achsen betrachtetwerden und jeder Schnittpunkt von Artikel- und Standortskoordinateninnerhalb eines durch eine orthogonale Anordnung dieser Achsen definiertenBereichs als ein (Artikel, Standort)-Punkt in einem zweidimensionalenEntitätsraum betrachtetwird, bei dem solche Attribute gespeichert werden, wird das Konzeptklar.
[0030] DasBeispiel kann weiter dahingehend erweitert werden, dass Attributemit eingeschlossen werden, die von der Kombination einer beliebigen Anzahlbeliebiger Entitätsdimensionenabhängen, waszum Konzept von Attributen als generalisierte Daten führt, diean Punkten in einem n-dimensionalen Entitätsraum gespeichert und vondiesen abgerufen werden. Zum Beispiel könnte ein bestimmter für ein beispielhaftesEinzelhandelsunternehmen geeigneter dreidimensionaler Entitätsraum Dimensionen für Artikel,Standorte und Zeiten beinhalten, wobei die am jeweiligen (Artikel,Standort, Zeit)-Punktinnerhalb eines durch eine orthogonale Anordnung dieser Achsen definiertenVolumens gespeicherten Attribute einer bestimmten Kombination vonEntitätenin der Artikel-, der Standorts- und der Zeitdimension entsprechen.In einer Ausführungsformkönnenalle im MDM-System 4 gespeicherten Referenzdaten 22 zueinem Attribut äquivalentsein, das einem Punkt im n-dimensionalen Entitätsraum zugeordnet ist.
[0031] Ineiner Ausführungsformist eine vorherrschende Charakteristik aller Daten, die zur Aufnahmein das MDM-System 4 in Betracht gezogen werden, das obenbeschriebene mehrdimensionale Datenbankkonstrukt. Daher kann einarchitektonisches Kernprinzip für dasMDM-System 4 die Unterbringung einer dimensionalen Datenstrukturals ein Kernelement in jeder Komponente des MDM-Systems 4 sein.Dies kann mehrere wichtige Auswirkungen für die MDM-Architektur und derenAufbau haben. Solche wichtigen Auswirkungen können zum Beispiel, ohne Einschränkung, sein:(1) ein konsistenter Mechanismus zum Lokalisieren von Punktenin einem n-dimensionalen Entitätsraum;(2) ein konsistenter Mechanismus zum Speichern von Datenan Punkten in einem n-dimensionalenEntitätsraumund zum Abrufen der Daten von diesen; und (3) die Gewährleistung,dass alle einzelnen Datenspeicherungskomponenten das Obige unterstützen.
[0032] Einweiteres grundlegendes Konzept fürdas MDM-System 4 kann die Optimierung der physischen Architekturund Datenbankstrukturen fürdie gewünschtenFunktionen des MDM-Systems 4 betreffen. Der Kern-MDM-Referenzdatenspeicherist, wie oben beschrieben, hauptsächlich für die Datenverwaltung und istzum Vorsehen einer reichhaltigen Datenverwaltungsstruktur aufgebaut.Auf der anderen Seite könnenEingabe- und Ausgabedatenaufbereitungs-und Verteilungselemente des MDM-Systems 4 einen effizientenDatentransfer und -durchsatz erfordern. Während viele Systeme versuchthaben, eine Kompromissarchitektur zur Bewältigung aller dieser Bedürfnissebereitzustellen, ist das MDM-System 4 vorzugsweise so strukturiert,dass jedes Element zum optimalen Erfüllen seiner entsprechendenFunktionen ausgelegt ist.
[0033] DasMDM-System 4 kann fürUnternehmen in verschiedenen industriellen Zusammenhängen, wiezum Beispiel Handel, herstellende Industrie oder in anderen industriellenZusammenhängenseinen Wert entwickeln. Auch wenn zu Zwecken der VeranschaulichungBeispiele aus dem Einzelhandel gegeben werden, wird bei der vorliegendenErfindung in Betracht gezogen, dass das MDM-System 4 imZusammenhang mit einem beliebigen geeigneten Unternehmen und aufdessen Bedürfnissezugeschnitten eingesetzt wird. Die MDM-Architektur und die MDM-Konstruktionsind vorzugsweise so aufgebaut, dass Elemente bereitgestellt werden,die einen erfolgreichen Einsatz des MDM- Systems 4 über viele verschiedene Branchentypenund viele verschiedene Unternehmen innerhalb eines bestimmten Branchentypshinweg gewährleisten.
[0034] Wieoben beschrieben, beinhaltet das MDM-System 4 eine Prozessschicht 12,die den Kontext zum Implementieren und ganzen oder teilweisen Automatisierenvon Geschäftskonfigurationsprozessen 14 liefert.Allgemein liefern die Prozesse 14 Funktionen, die zum Realisierenvon Prozessarbeitsabläufennotwendig sind, die als ein Teil der MDM-Lösungzur Verfügunggestellt werden, wodurch Unternehmensaktivitäten Struktur verliehen wirdund es bei diesen Aktivitätenmöglichwird, dass sie wiederholt, gesteuert, überwacht und mit der Zeit verbessert werden.Jeder Prozess 14 repräsentierteine Abfolge von Aufgaben, die zusammen eine Geschäftsaktivität abwickeln.Das MDM-System 4 kann native Unterstützung für generische Prozesse 14 undUnterstützung,die fürbestimmte Prozesse 14 spezifisch ist, bereitstellen. Ineiner Ausführungsformermöglichen esdie Prozesse 14, dass reichhaltige Geschäftsarbeits-abläufe (RichBusiness Work Flows) in das MDM-System 4 eingebettet sindund unter der Verwendung der Ressourcen innerhalb der darunter liegendenDienst- und Datenschichten 16 bzw. 20 unterstützt werden.In einer Ausführungsformstellt das MDM-System 4 eine höchst konfigurierbare, flexible underweiterbare Umgebung zur Implementierung und ganzen oder teilweisenAutomatisierung beliebiger geeigneter Prozesse 14 zur Verfügung.
[0035] DieProzesse 14 könnenauf zwei Ebenen wirken. Die erste Ebene, die Unternehmensebene, kanngrößer ausgelegteIntra- und Inter-Unternehmensprozesse 14 beinhalten, dieder Verwaltung von Daten dienen, da sie mit den angestrebten Zielender MDM-Lösungzusammenhängt.Wo das MDM-System 14 zum Beispiel zu einem Einzelhandelsunternehmengehört,kann ein Beispiel eines Prozesses 14 der ersten Ebene einProzess 14 zur Einführung einesneuen Artikels sein, bei dem sich auf einen neuen Artikel beziehende,extern erzeugte Daten im Kern-MDM-Referenzdatenspeicher abzulegensind.
[0036] Diezweite Ebene kann kleiner ausgelegte Managementprozesse 14 beinhalten,bei denen innerhalb des MDM-Systems 4 befindliche Datenbewegt werden, wie zum Beispiel das Abrufen von Daten aus dem Kern-MDM-Referenzdatenspeicherim Zusammenhang mit Abfragen von der Benutzerschnittstelle, mitder Analyse oder mit anderen Diensten innerhalb des MDM-Systems 4.
[0037] ZumBeispiel könnengenerische Prozesse 14, die auf ein beliebiges Unternehmenund eine beliebige Dimensionierung des MDM-Systems 4 angewendetwerden können,ohne Einschränkung,sein: (1) Die Einführungeiner neuen Entität;(2) die Entitätspflege;(3) die Metadaten-Neuordnung; (4) die Entitätsextraktion; und (5) die Entitätsreplikation.
[0038] DieserProzess 14 stellt die Einführung einer neuen Entität in dasMDM-System 4 dar. Fürein Beispiel-Einzelhandelsunternehmen kann dies die Einführung einesneuen Artikels, Standorts, Zulieferers oder Kunden beinhalten. DerProzess 14 kann durch das dem MDM-System 4 zugeordneteUnternehmen oder durch ein beliebiges anderes Unterneh-men, wiezum Beispiel einen Zulieferer eines neuen einzuführenden Artikels angestoßen werden.Ein einen neuen Artikel liefernder Zulieferer kann als ein Beispielfür einenAustausch von Inhalten betrachtet werden. In jedem Fall muss dasdem MDM-System 4 zugeordneteEinzelhandelsunternehmen fürden neuen Artikel unternehmensspezifische Daten dem MDM-System 4 hinzufügen, dieDaten validieren, die Verwendung des neuen Artikels genehmigen unddie Verfügbarkeitdes neuen Artikels zur Verwendung durch die Planungs-, Ausführungs-, Überwachungs- oderanderen Unternehmenslösungskomponenten 6 veröffentlichen,möglicherweisedurch Replikation. Ein Beispiel für einen Prozess 14 zurEinführungeines neuen Artikels ist unten anhand von 10 eingehender beschrieben.
[0039] Beidiesem Prozess 14 werden eine oder mehrere Charakteristikeneiner bestehenden Entität, wiezum Beispiel eines Artikels, Standorts, Zulieferers oder Kundenfür einBeispielhandelsunternehmen, aktualisiert. Der Prozess 14 kanndurch das dem MDM-System 4 zugeordnete Unternehmen oder einbeliebiges anderes Unternehmen, wie zum Beispiel einen Zulieferereines Artikels, fürden ein oder mehrere Charakteristiken zu aktualisieren sind, angestoßen werden.Zum Beispiel kann ein "verbesserter" Artikel im Wesentlichenseine ursprünglicheTeilenummer und seine Artikelnummer (Stock Keeping Unit/SKU) beibehalten,jedoch werden ein oder mehrere seiner Primärattribute vom Zulieferer geändert, wiezum Beispiel die Größe, dasGewicht oder die Farbe. In ähnlicherWeise kann das Einzelhandelsunternehmen ein oder mehrere Sekundärattributeeines bestehenden Artikels verändern.
[0040] DieserProzess involviert die Bewegung innerhalb einer Dimension von einemoder mehreren Elementen von einer Ebenen-Beziehung zu einer anderenEbenen-Beziehung in einer dimensionalen Hierarchie. Ein Einzelhandelsunternehmenkann zum Beispiel einen Artikel von einer Klasse in eine andereKlasse bewegen, was wiederum die Identifikation des einen oder dermehreren zu ändernden Elementeund der Ziel-Beziehungen erfordert. Es kann notwendig sein, dassder Prozess 14 entsprechende Prüf- und Journalspuren hinterlässt undeinen oder mehrere Genehmigungs-Unterprozesse erfordert.
[0041] Beidiesem Prozess 14 werden Selektionskriterien für eine odermehrere Entitätenzur Verfügung gestellt,eine entsprechende Abfrage durchgeführt und die entsprechenden Datenbewegt oder anderweitig der anfragenden Rolle oder dem anfragenden Untersystemverfügbargemacht.
[0042] Beidiesem Prozess 14 werden Daten im MDM-System 4 ganzoder teilweise fürandere Subsysteme zur internen Verwendung repliziert. Eine solcheReplikation kann es ermöglichen,die Daten in effizienterer Weise als durch einen direkten operativen Zugriffauf den Kern-MDM-Referenzdatenspeicher zu verwenden.
[0043] Wieoben beschrieben, stellt die Dienstschicht 16 Dienste 18 zurVerfügung,die Funktionen bereitstellen, welche die Konstruktion von Prozessaufgabenerlauben, die fürdie Prozesse 14 geeignet sind. Jeder Dienst 18 stellteine nützlicheArbeitseinheit bereit oder ermöglichteine Prozessaufgabe im Kontext des MDM-Systems 4. Die Dienste 18 sind keineProzesse 14. Vielmehr ist ein Dienst 18 eher vergleichbarmit einer Aufgabe innerhalb eines Prozesses 14 oder einerAktion in Reaktion auf eine Anfrage im Zusammenhang mit einem Prozess 14,wie zum Beispiel die Berechnung des Werts einer Funktion im Zusammenhangmit dem Dienst 18 oder die Ausgabe einer Anfrage zum Betrachten,Aktualisieren oder Löschenvon Information im Kern-MDM-Referenzdatenspeicher.In einer Ausführungsformsind Dienste 18 innerhalb der Dienstschicht 16 des MDM-Systems 4 für ein Beispiel-Einzelhandelsunternehmen,jedoch ohne Einschränkung:(1) Entitätspflegedienste 18a;(2) Metadatenpflegedienste 18b; (3) Parameterpflegedienste 18c;(4) Attribut/Merkmalsdienste 18d; (5) Ereignis (Kalender)-Dienste 18e;(6) Lieferkettennetzwerkdienste 18f; (7) Bezugsdienste 18g;(8) auf Prozesskostenrechnung (Activity Based Costing/ABC) bezogeneDienste 18h; (9) Vertragsdienste 18i; und (10)Stücklistendienste (billof materials/BOM) 18j.
[0044] Entitätspflegedienste 18a liefernGrundfunktionen zum Navigieren, Zugreifen, Filtern und Sortierenvon Entitäteninnerhalb des MDM-Systems 4. Für ein Beispiel-EinzelhandelsunternehmenkönnenArtikel, Standorte, Zulieferer und Kunden Typen von Entitäten sein,die innerhalb des MDM-Systems 4 verwaltet und unter derVerwendung der Entitätspflegedienste 18a gepflegtwerden.
[0045] Metadatenpflegedienste 18b liefernGrundfunktionen fürdie Konstruktion, Verwaltung und die Neuordnung entsprechender Metadaten.Zum Beispiel könnenMetadaten solche Metadaten sein, welche das Unternehmen in seinerGänze,die Struktur des MDM-Systems 4, die Strukturen der Datenaufbereitungsbereichedes MDM-Systems 4 und die Beziehungen zwischen den Datenaufbereitungsbereichen unddem Kern-MDM-Referenzdatenspeicherbeschreiben. Solche Funktionen könnendie Fähigkeit zumSchaffen von Dimensionen und zum Definieren von Hierarchien in denDimensionsräumensein, wobei jede Hierarchie eine Anzahl von Ebenen hat, von denenjede eine Anzahl von Elementen enthält. Diese Funktionen können auchdie Pflege bezüglichder Dimensionen, Ebenen und Elemente beinhalten, wie zum Beispieldie Anlage, Modifikation oder die Löschung solcher Metadatenelemente.
[0046] Parameterpflegedienste 18c liefernGrundfunktionen fürdie Pflege, die Verwaltung und Verteilung von Unternehmenslösungs-Komponentenparametern(d.h. Geschäftsregelparametern).Ein oder mehrere Parameter können,aber müssennicht, für eineoder mehrere bestimmte Unternehmenslösungskomponenten 6 spezifischsein. Jeder Parameter kann an eine oder mehrere Entitäten gebunden seinund als solches als ein Sekundärattributder Entitätenbetrachtet werden. (Im Gegensatz zu Primärattributen, wie die Größe, dasGewicht und die Farbe eines Beispielartikels). Parameterpflegedienste 18c liefernFunktionen, die fürdiese Typen von Attributen besonders geeignet sind. Das MDM-System 4 kann nichtnur einen Speicher fürsolche Attribute bereitstellen und das Abrufen dieser Attributefür dieVerwendung ermöglichen,sondern kann auch ein standardisiertes Verwaltungsmuster für alle Parameterin der gesamten Unternehmenslösungliefern. In einer Ausführungsformhat dies den vorteilhaften Effekt des Lieferns einer gleichmäßigen Methodikfür die Parameterverwaltungund nimmt punktuellen Lösungskomponentendie Aufgabe des Lieferns dieser Funktionalitäten ab.
[0047] MancheAttribute von Entitätensind quantitativ, eindeutig definiert und über die Zeit stabil. Beispielesolcher Attribute sind die Größe, dasGewicht und die Farbe eines Artikels oder die Adresse eines Zulieferers.Andere Attributtypen sind eher qualitativ, nicht so eindeutig definiertund könnensich überdie Zeit ändern.Diese Attribute, die auch als Merkmale (Traits) bezeichnet werdenkönnen,sind oft fürein kundenzentrisches Marketing nützlich und dienen als die Grundlagezur Erzeugung von Attribut/Merkmals-Clustern. Attribut/Merkmals-Dienste 18d liefern diefür diesenDatentyp, der sich im MDM-System 4 befindet oder unterseiner Verwendung verwaltet wird, geeigneten Funktionen. Da dieAnzahl und sogar die Typen dieser Attribute/Merkmale typischerweiseim Voraus nicht bekannt sind, sind die Anforderungen an die physischeStruktur eines Systems zur Bewältigungdieses Datentyps etwas anders als die für statischere Masterdaten.Attribut/Merkmals-Dienste 18d liefern grundlegende Funktionen zurSchaffung, Pflege und Verwendung dieses Datentyps und können auchfortgeschrittenere Dienste, wie zum Beispiel Attribut/Merkmals-Clusteringdienstebeinhalten.
[0048] Ereignis-oder allgemeiner Kalenderdienste 18e erledigen die Verwaltungzeitbezogener Aktivitäten.Diese Dienste 18e liefern die grundlegenden Funktionenzur Erstellung von Referenzkalendern und zur Schaffung und Verwaltungzeitbezogener Aktivitäten(d.h. auf bestehende Kalender bezogene Ereignisse).
[0049] Lieferketten – Netzwerkdienste 18f liefern diegrundlegenden Funktionen zum Unterstützen der Definition und derVerwendung des physischen Lieferkettennetzwerks, das einem Unternehmenzugeordnet ist. Das Lieferkettennetzwerk ist für viele Planungs-, Durchführungs-, Überwachungs-und andere Unternehmenslösungs-komponenten 6 entscheidend,die unter Verwendung des MDM-Systems 4 unterstützt werden.
[0050] Bezugsdienste 18g lieferndie grundlegenden Funktionen zum Zugreifen auf die Elemente des MDM-Modellsund zu deren Verwendung, die fürBezugslösungskomponentenrelevant sind, wie zum Beispiel eine Zulieferer-Beziehungs-Verwaltungslösungskomponente.
[0051] EineAnzahl nützlicherMaßnahmenkönnen Entitäten zugeordnetwerden, wie zum Beispiel Artikeln, bei denen das MDM-System 4 einemBeispieleinzelhandelsunternehmen zugeordnet ist, die herkömmlicherweisenicht im Zusammenhang mit einem Artikelkatalog oder einem ähnlichenKonstrukt standen. Diese Maßnahmenkönneneine nützlichefortgeschrittene Analyse ermöglichen.Ein Beispiel dafür sindArtikeln zugeordnete Kosten- und Preisdaten. Diese Daten können für eine fortgeschrittenePreisoptimierung und fürProzesskostenrechnungsanalysen verwendet werden. In einer Ausführungsformliefert das MDM-System 4 Modelle zur Erfassung von Kostendaten,wie zum Beispiel Kostenelemente, die nach ihrer Zusammenfassungdie gesamten Kosten der Waren bis zur Anlieferung repräsentieren.In diesen Modellen inbegriffen sind Kosten, die Aktivitäten, wiezum Beispiel der Handhabung eines Artikels, zugeordnet sind, während erPunkte im zugeordneten Lieferkettennetzwerk durchläuft. Prozesskostenrechnungsdienste 18h lieferngrundlegende Funktionen zur Handhabung von Prozesskostenrechnungsdaten,die im MDM-System 4 gespeichert und unter seiner Verwendungverwaltet werden. Außerdemsind Daten, wie zum Beispiel normalisierte Bedarfsprofile (oderZuordnungen zu solchen Profilen) Beispiele für Sekundärattribute, die das MDM-System 4 möglicherweiseunterstützenmuss.
[0052] Ineiner Ausführungsformerzeugt oder verwaltet das MDM-System 4 nicht inhärent Verträge für ein Beispieleinzelhandelsunternehmen.Das MDM-System 4 stellt jedoch vorzugsweise einen Speicherfür Vertragsdatenbereit, da diese sich auf im MDM-System 4 gespeicherteEntitätenbeziehen, und bietet einen zentralen Verteilungsmechanismus für Vertragsdatenan entsprechende Unternehmenslösungskomponenten 6.Die Vertragsdienste 18i liefern grundlegende Funktionenzum Eingeben, Zuordnen und Verteilen von mit Verträgen zusammenhängendenDaten, die sich auf sich im MDM-System 4 befindende Kernunternehmensdatenbeziehen.
[0053] Für ein Beispieleinzelhandelsunternehmen liefernStücklistendienste 18j grundlegendeFunktionen zum Erzeugen, Verwalten und Visualisieren von Stücklistenfür dasUnternehmen. Zum Beispiel kann es sein, dass eine einzelne tatsächlicheStücklistefür Planungszweckezu kleinteilig ist, so dass eine geeignete Zusammenfassung eineroder mehrerer tatsächlicherStücklistenin eine fürPlanungszwecke geeignete Darstellung zum Unterstützen eines dem MDM-Systems 4 zugeordnetenPlanungssystems notwendig ist. Das MDM-System 4 kann solcheDarstellungen als Referenzdaten speichern und sie nach Bedarf Planungs-oder anderen externen operativen Systemen zur Verfügung stellen.Das MDM-System 4 kann ebenfalls solche Darstellungen aufder Grundlage eines MDM-Stücklistenmodellsautomatisch generieren, um die Notwendigkeit einer manuellen Auswertungund Ansammlung einzelner tatsächlicher Stücklistenzum Erzeugen dieser Darstellungen zu verringern oder auszuschließen. DieStücklistendienste 18j unterstützen vorzugsweisedie Elemente jedes geeigneten MDM-Stücklistenmodells.
[0054] DasMDM-System 4 befasst sich grundsätzlich mit der Fähigkeitdes Schaffens, Manipulierens und Extrahierens von Daten im Zusammenhangmit der Unternehmenslösung.Wie oben beschrieben, liefert die Datenschicht 20 die Basisdatenmodelle undphysischen Darstellungen zum Speichern verschiedener Typen von Unternehmensreferenzdaten 22,um sie im Zusammenhang mit Prozessen 14 und entsprechendenDiensten 18 abzurufen und einzusetzen. In einer Ausführungsformsind Referenzdaten 22 in der Datenschicht 20 desMDM-Systems 4 fürein Beispieleinzel-handelsunternehmen zum Beispiel, jedoch ohneEinschränkung:(1) Masterdaten 22a; (2) Metadaten 22b; (3) Unternehmensmodelle 22c;(4) Parameterdaten 22d; (5) Attribut/Merkmals-Daten 22e;(6) Ereignis (Kalender) – Daten 22f; (7)Lieferketten-Netzwerkdaten 22g; und (8) Prozesskostenrechnungsdaten 22h.
[0055] DieMasterdaten 22a repräsentierenKernkonfigurationsdaten, die Entitäten, wie zum Beispiel Artikeln,Standorten, Zulieferern und Kunden für ein Beispieleinzelhandelsunternehmenzugeordnet sind. Viele Aspekte der Wertkettenverwaltung im Allgemeinenund insbesondere die meisten Planungs-, Ausführungs-, Überwachungs- oder anderen Unternehmenslösungskomponenten 6 erfordernReferenzdaten 22 darüber,welche Artikel verkauft werden, welche Standorte die Artikel verkaufen,welche Zulieferer die Artikel liefern, welche Kunden die Artikelkaufen und andere grundlegende Datenelemente, auf denen alle anderenUnternehmensdaten aufgebaut sind oder mit denen alle anderen Unternehmensdatenin irgend einer Weise in Beziehung stehen. Das MDM-System 4 kanndas herkömmlicheKonzept von Masterdaten bezüglichsolcher Entitätendahingehend erweitern, dass komplexe Geschäftsarbeitsabläufe, diefür eineUnternehmenslösungangestrebt werden, umgesetzt werden können. Auch wenn Altmasterdatenbestände, wiezum Beispiel Artikeldatenbestände,Attribute von Artikeln, wie zum Beispiel Artikelnummern erfassen,die angeben, wo die Artikel in die hierarchische Struktur der Unternehmensdatenhineinpassen, besteht keine Garantie, dass ein Altsystem diese Datenin einem dimensionalen Sinn manipulieren oder sogar sichten könnte. Ineiner Ausführungsformkann ein Artikel oder ein anderer Master für das MDM-System 4 Datenin dimensionaler Weise erzeugen, manipulieren, navigieren, einsehen undextrahieren.
[0056] Ineiner Ausführungsformrepräsentierteine Entitätinnerhalb eines Masterdatentyps ein atomisches Element dieses Typs,wie zum Beispiel einen bestimmten Artikel, einen bestimmten Standort,einen bestimmten Zulieferer oder einen bestimmten Kunden. Attributevon Entitäten,wie zum Beispiel Artikel, Standorte und dergleichen können wichtigeRollen bezüglichPlanungs-, Ausführungs-, Überwachungs-und anderen Unternehmenslösungskomponenten 6 spielen.Ein erster Typ eines Entitätsattributsist ein physisches oder primäresAttribut, das allgemein inhärentenCharakteristiken der Entität,wie zum Beispiel der Größe, demGewicht und der Farbe füreine Beispiel-Artikelentität,zugeordnet ist. Primärattributekönnenzum Beispiel beim Planen von Produktsortimenten oder bei der Lösung vonLogistikproblemen im Zusammenhang mit dem Versand einer Bestellungfür einenArtikel sehr wichtig sein. Primärattibutesind einigermaßenstatisch und erfordern keinen anderen Bedeutungskontext als diezugeordnete Entitätselbst. Ein zweiter Typ von Entitätsattribut existiert als Folgeder Verwendung der Entitätinnerhalb des Unternehmens, die zu einer definierten Beziehung derEntitätzu einer anderen Entitätoder zu einem externen Maß führen kann.Ein Beispiel fürein solches Attribut eines Artikels kann die Kategorie oder Unterkategorieinnerhalb des Unternehmens sein, der der Artikel zugewiesen wird.Dieser Attributtyp, der oft auch als qualitatives oder sekundäres Attributbezeichnet wird, kann fürfortgeschrittenere Analysetechniken, wie zum Beispiel Artikelgruppierung/Clustering,kundenorientierte Werbung und Verkaufsförderungen sehr wichtig sein.In einer Ausführungsformermöglichenes die Masterdaten 22a dem MDM-System 4 sowohl primäre als auch sekundäre Attributevon Entitätenzu verwalten.
[0057] Eskann wichtig sein, zwischen Daten zu unterscheiden, die als Masterdaten 22a betrachtetwerden, und Daten, die als Attribut/Merkmals-Referenzdaten 22e betrachtetwerden, die noch beschrieben werden. Wie oben erwähnt, können dieMasterdaten 22a einigermaßen statisch sein und sichnicht über dieZeit schnell verändern.Zum Beispiel kann es sein, dass eine Farbe (Primärattribut) eines bestimmtenHemdes sich übereine Saison, in der das Hemd verkauft wird, nicht ändert. Auchwenn es sein kann, dass sich die Unterkategorie innerhalb des Unternehmens,der das Hemd zugewiesen ist (Sekundärattribut), ändern kann,zum Beispiel als Folge einer Neuordnung, sind solche Veränderungenwahrscheinlich selten. Im Gegensatz dazu können zum Beispiel Attribut/Merkmalsdaten 22e für zielgerichteteSortimente häufigeingesetzt werden und müssendaher das dynamische Verhalten der Kunden widerspiegeln. Außerdem können dieAttribute/Merkmale selbst Änderungenunterworfen sein, wobei gegebenenfalls neue Attribute/Merkmale hinzugefügt werdenund bestehende Attribute/Merkmale, die keine Gültigkeit mehr haben, gegebenenfallswegfallen.
[0058] Eineweitere Form von Referenzdaten 22, die den oben beschriebenenEntitätsmasterninhärentist und fürviele Unternehmenslösungskomponenten 6 sehrwichtig ist, sind Unternehmensmetadaten 22b. Allgemeinsind Metadaten 22b Daten, die andere Daten beschreiben.Im Kontext des MDM-Systems 4 beschreiben Metadaten 22b die Stukturder im MDM-System 4 gespeicherten und verwalteten Daten.Allgemein liefern Metadaten 22b eine Beschreibung der Strukturder dimensionalen Sicht der Masterdaten 22a. Die vorliegendeBeschreibung konzentriert sich darauf, welche Dimensionen bestehen,welche Ebenen die Dimensionskoordinaten beschreiben und welche Elementebestehen und den Ebenen zugeordnet sind. Zusätzlich können Navigationskonstruktedefiniert werden, die als Hierarchien bezeichnet werden. Zum Beispielkönntenfür einBeispieleinzelhandelsunternehmen Metadaten 22b die verschiedenenEbenen der Taxonomie von Artikeln und eine oder mehrere Hierarchienzum Navigieren durch die verschiedenen Ebenen der Taxonomie enthalten.In einer Ausführungsformerfasst das MDM-System 4 Metadaten 22b in einerForm, die fürnachgeschaltete Unternehmenlösungskomponenten 6 wirksamrepliziert werden kann, welche eine Konsistenz in der dimensionalenSicht der Masterdaten 22a benötigen. Wie oben im Zusammenhangmit den Metadatenpflegediensten 18b beschrieben, kann dasMDM-System 4 die Schaffung, Manipulation und Löschung vonMetadaten 22b verwalten und eine Neuordnung von Stammdaten 22a (z.B.das Bewegen eines Artikels von einer ersten Kategorie in eine zweiteKategorie) liefern, so dass sich jede Neuordnung in den Metadaten 22b entsprechendwiderspiegelt.
[0059] Unternehmensmodelle 22c repräsentieren Organisationssichtender Rollen innerhalb eines Unternehmens. In einer Ausführungsformkönnensich die Unternehmensmodelle 22c über die Unternehmensgrenzehinweg erstrecken, um alle Organisationselemente der dem Unternehmenzugeordneten Wertkette abzudecken. Unternehmensmodelle 22c können bezüglich derAuthentifizierungs- und Autorisierungsaspekte des Datenzugriffswichtig sein. ZusätzlichkönnenUnternehmensmodelle 22c Genehmigungskettenbeziehungen bereitstellen,die fürdie Geschäftsprozessverwaltungwichtig sind.
[0060] 3 zeigt ein Beispiel für eine logische technischeArchitektur 30 des MDM-Systems 4.Allgemein stellt die logische technische Architektur 30 einetechnologiezentrische Sicht des MDM-Systems 4 dar und spezifiziertlogische Elemente des MDM-Systems 4,die zusammen betrieben werden können,um die gewünschteMDM-Lösungbereizustellen. In einer Ausführungsformbeinhaltet die logische technische Architektur 30 eineMDM-Dienststruktur 32, die Kern-MDM-Dienste 34 enthält. Die MDM-Datenbank 36 enthält den Kern-MDM-Referenzdatenspeicher.Bestimmte Dienste 34 können aufbeliebige Klassen von Referenzdaten 22 angewendet werden,um im Kern-MDM-Referenzdatenspeichermodelliert zu werden. Andere Dienste 34 können aufbestimmte Klassen von Referenzdaten 22, die im Kern-MDM-Referenzdatenspeichermodelliert sind, zugeschnitten sein. Weitere Dienste 34 können verschiedeneSicherheits-, Datenzugriffs-, Datenaufbereitungs- und andere Datenverwaltungsbedürfnissegenerisch unterstützen.Beispiele für Dienste 34 sindunten eingehender beschrieben. Entsprechende Dienste 34 können unterder Verwendung einer oder mehrerer entsprechender Datenzugriffsverbindungen 38 aufdie Datenbank 36 zugreifen.
[0061] Externeoperative Systeme 40 könnenunter Einsatz einer oder mehrerer Datenzugriffsschichten 42 aufdie Datenbank 36 zugreifen. In einer Ausführungsformkann ein externes operatives System 40 im Zusammenhangmit einem Geschäftsarbeitsablaufunter der Verwendung einer front side – Datenzugriffsschicht 42a eineszugeordneten front side – Busses 44a zwischendem externen operativen System 40 und der front side – Datenzugriffsschicht 42a undeiner zugeordneten Datenschnittstelle 46a zwischen derfront side – Datenzugriffschicht 42a und derDatenbank 36 auf die Datenbank 36 zugreifen. Diefront side – Datenzugriffsschicht 42a wirdtypischerweise zum Weiterleiten von Steuerdaten von externen operativenSystemen 40 an das MDM-System 4 zum Steuern vonMDM-Vorgängen verwendet undkann im Zusammenhang mit einer Anwendungsintegration stehen. Einoder mehrere Dienste 34 können auf die front side – Datenzugriffsschicht 42a unterder Verwendung einer oder mehrerer geeigneter Datenzugriffsverbindungen 48 zugreifen.Ein externes operatives System 40 kann unter der Verwendungeiner back side – Datenzugriffsschicht 42b,eines entsprechenden back side – Busses 44b zwischendem externen operativen System 40 und der back side – Datenzugriffsschicht 42b undeiner zugeordneten Datenschnittstelle 46b zwischen derback side – Datenzugriffsschicht 42b undder Datenbank 36 auf die Datenbank 36 zugreifen.Die back side – Zugriffsschicht 42b wirdtypischerweise zur Bewegung von Referenzdaten 22 und vonexternen operativen Systemen 40 verwendet und kann im Zusammenhangmit einer Datenintegration stehen. Die front side – Datenzugriffsschicht 42a kannjedoch gegebenenfalls auch zum Bewegen von Referenzdaten 22 zuund von externen operativen Systemen 40 eingesetzt werden,zum Beispiel in dem Fall, wo ein externes operatives System 40 ineinem bestimmten nachrichtenbasierten oder anderen Format bestimmteReferenzdaten 22 benötigt.
[0062] 4 zeigt ein Beispiel für eine logischeDatendienstarchitektur 50 des MDM-Systems 4. In einer Ausführungsformenthältdie Datendienstarchitektur 50 Primärschichten: (1) eine frontside – Datendienstschicht 52a'' (2) eine physische Datenschicht 54;und (3) eine back side – Datendienstschicht 52b.Die front side – Datendienstschicht 52a istder front side – Datenzugriffsschicht 42a,die oben anhand von 3 beschriebenwurde, zugeordnet und liefert direkten Datenzugriff für die internenMDM-Dienste 34, die direkt auf den Kern-MDM-Referenzdatenspeicherin der Datenbank 36 zugreifen. Zum Beispiel kann die frontside – Datendienstschicht 52a einendirekten Zugriff auf die Datenbank 36 zur internen Analyse oderfür Benutzerschnittstellen-dienstabfragenliefern. Die physische Datenschicht 54 enthält die Datenbank 36,in der sich das Kern-MDM-Referenzdatenmodell befindet. Die backside – Datendienstschicht 52b istder back side – Datenzugriffsschicht 42b,die oben anhand von 3 beschriebenwurde, zugeordnet und liefert einen indirekten Datenzugriff für externeoperative Dienste 56, die mit externen operativen Systemen 40 zusammenhängen, dieindirekt auf den Kern-MDM-Referenzdatenspeicher in der Datenbank 36 zugreifen.Zum Beispiel kann die back side – Datendienstschicht 52b operativeDienste mit einem indirekten Zugriff auf die Datenbank 36 durchdie Aufbereitungsbereiche der Datenbank 36, Aufbereitungsbereiche,die mit externen operativen Systemen 40 in Zusammenhangstehen, und persistente Datenspeicher, die externen operativen Systemen 40 zugeordnetsind, bereitstellen. In einem physischen Einsatz kann jede der dreiPrimärschichten derDatendienstarchitektur 50 auf entsprechende technischeKomponenten abgebildet werden.
[0063] Diefront side – Datendienstschicht 52a kann aufeine entsprechende objektbasierte Dienstschicht abgeildet werden,wie zum Beispiel Common Object Request Broker Architecture (CORBA)oder JAVA 2 PLATFORM ENTERPRISE EDITION (J2EE), die sich auf einementsprechenden Anwendungsserver innerhalb einer Anwendungsserverschicht(die unten anhand von 9 beschriebenist) befindet. In bestimmten Ausführungsformen kann die frontside – Datendienstschicht 52a mitder physischen Datenschicht 54 enger gekoppelt sein, wasan der Notwendigkeit einer Objekt-zu Relational-Übersetzungsschichtals Teil der front side – Datendienstschicht 52a liegt.
[0064] DieDatenbank 36 innerhalb der physischen Datenschicht 54 kannals eine relationale Datenbank implementiert sein. Die Datenbank 36 kannin verschiedenen Arten und Weisen modelliert und verwaltet werden,von denen eine füreinen bestimmten Einsatz ausgewähltwerden kann. In einer Ausführungsformkann eine Objekt-Relational-Datenbankverwaltungstechnikverwendet werden, auch wenn diese Vorgehensweise typischerweisePerformance-Risiken unterliegt. Bei dieser Vorgehensweise kann das Kern-MDM-Referenzdatenmodellauf bestehende Dienste 34 unter der Verwendung einer geeigneten Objekt-Relational-Abbildungsschichtabgebildet werden. In einer alternativen Ausführungsform kann für eine verbessertePerformance oder aus anderen Gründeneine feste Datenmodell-Relational-Datenbank mit einer leichten Zugriffsschichtverwendet werden. Die leichte Zugriffsschicht würde auf das feste und optimiertephysische Schema der relationalen Datenbank zugeschnittene persistenteObjekte bereitstellen und das physische Schema nicht über eine Objekt-Relational-Abbildungsschichtansprechen. Mit dieser Vorgehensweise können neue Dienste 34 aufein bestehendes Kern-MDM-Referenzdatenmodell abgebildet werden.
[0065] Auchwenn hier aus Gründender Einfachheit hauptsächlichein einzelner Kern-MDM-Referenzdatenspeicherin einer einzelnen Datenbank 36 beschrieben ist, wird beider vorliegenden Erfindung eine beliebige Anzahl von Kern-MDM-Referenzdaten-speichernin einer beliebigen Anzahl von Datenbanken 36 je nach denbestimmten Bedürfnissenin Betracht gezogen. Jedoch unterliegen alle Kern-MDM-Referenzdatenspeicherinnerhalb aller Datenbanken 36 einer zentralen Datenverwaltungin Zusammenhang mit einem einzigen MDM-System 4 und erscheinenvorzugsweise sowohl den internen MDM-Diensten 34 als auch den externenoperativen Diensten 56 gegenüber als ein einziger Kern-MDM-Referenzdatenspeicher.
[0066] Dieback side – Datendienstschicht 52b ist vorzugsweisefür potenziellgroßeDatensynchronisations- und -replikationsvorgänge, vorzugsweise unter Einschlussvon Netzänderungstechniken,effizienten Speicherprozedurtechniken und einer objektbasiertenSteuerschicht optimiert. Außerdemsollte, da die back side – Datendienstschicht 52b aufPlanungs-, Ausführungs-, Überwachungs-oder andere Unternehmenslösungs-komponenten 6 abbildet,für die Datenbewegungenund zugeordnete Abbildungen (d.h. Trans formationen) über dieZeit relativ fest bleiben müssen,das Kern-MDM-Referenzdatenmodell ebenfalls über die Zeit relativ fest sein.
[0067] 5 zeigt ein Beispiel für eine logischeArchitektur 70 der Datenbank 36. In einer Ausführungsformumfasst die Datenbank 36 eine konsistente dimensionaleModellierungsstruktur, die auf ein einen PersistenzverwaltungsdienstunterstützendesModell aufgesetzt wurde, der unten eingehender beschrieben ist.Dies erlaubt es vorzugsweise der Dienststruktur 32, Referenzdaten 22 inder Datenbank 36 in einer Weise zu verwalten, die mit bestehendendimensionalen Sichten der Referenzdaten 22 konsistent ist.Wo das MDM-System 4 physischnicht alle Referenzdaten 22 enthält, erscheinen Referenzdaten 22,die im MDM-System 4 nicht physisch enthalten sind, vorzugsweiseso, als wärensie physisch im MDM-System 4 enthalten. Die Datenbank 36 enthält einenverwalteten Datenbereich 72, der die Referenzdaten 22 enthält, vondenen mindestens einige vom MDM-System 4 entfernt verwaltetwerden können.Der verwaltete Datenbereich 72 stellt den Kern-MDM-Referenzdatenspeicherfür dieReferenzdaten 22 zur Verfügung. Die Datenbank 36 kann aucheinen cache-gespeicherten Datenbereich 74 enthalten, dercache-gespeicherte Daten 76 enthält, die Referenzdaten 22 darstellen,die vom verwalteten Datenbereich 72 extrahiert, gemäß den Bedürfnissen einesoder mehrerer Elemente des MDM-Systems 4 unter der Verwendungeiner Datenverwaltungsstruktur 78 verarbeitet und als Referenzdaten 22 nachder vollständigenVerarbeitung wieder in den verwalteten Datenbereich 72 eingefügt wurden.Zum Beispiel kann die Datenverwaltungsstruktur 78 dem Prozesscontrollerinnerhalb des Geschäftsprozess-Werkzeugs 34a,den Benutzerschnittstellendiensten 34d oder einem anderengeeigneten Element des MDM-Systems 4 einen operativen Zugriffauf cache-gespeicherte Daten 76 bieten.
[0068] Dieim MDM-System 4 gespeicherten Referenzdaten 22 habeneinen mit ihrer Verwendung konsistenten zugewiesenen Zustand. Ineiner Ausführungsformim Zusammenhang mit der Datenverwaltungsstruktur 78 stelltder cache-gespeicherte Datenbereich 74 einen Mechanismusbereit zum Aufnehmen einer Kopie der Referenzdaten 22 zurManipulation, währendder Zustand der Referenzdaten 22 im verwalteten Datenbereich 72 sogesperrt ist, dass nur Lesezugriff besteht, bis der Manipulationsvorgang abgeschlossenist. Sobald eine Kopie der Referenzdaten 22 als cache-gespeicherteDaten 76 im cache-gespeicherten Datenbereich 74 während des Manipulationsvorgangsgehalten wird, sieht der Manipulationsvorgang nur den Zustand dercache-gespeicherten Daten 76 im cache-gespeicherten Datenbereich 74,währendandere Prozesse, Dienste und Systeme im Zusammenhang mit dem MDM-System 4 denwahren Zustand der Referenzdaten 22 im verwalteten Datenbereich 72 undnicht einen Zwischenzustand sehen, der den immer noch unvollständigen Manipulationsvorgangwiderspiegelt.
[0069] DieDatenbank 36 kann auch einen operativen Zugriffsbereich 80 enthalten,der einem oder mehreren externen operativen Systemen 40 einen Zugangzu den Referenzdaten 22 innerhalb des verwalteten Datenbereichs 72 verschafft.Wo das MDM-System 4 einem Beispieleinzelhandelsunternehmenzugeordnet ist, könnendie externen operativen Systeme 40 externe Unternehmen,wie zum Beispiel Hersteller, Vertriebshändler, und Zulieferer dem Unternehmenzugeordneter Artikel umfassen. Die externen operativen Systeme 40 können auchPlanungs-, Ausführungs-, Überwachungs-und andere Unternehmenslösungskomponenten 6 innerhalbdes Unternehmens jedoch außerhalbdes MDM-Systems 4 umfassen. Der operative Zugriffsbereich 80 kann eineMasterkopie 82 eines Lightweight Directory Access Protocol(LDAP)-Speichers enthalten, die, wie unten weiter beschrieben, zumBereitstellen von Authentifizierungs- und Autorisierungsdienstenverwendet wird. Der operative Zugriffsbereich 80 kann auch Eingangs-und Ausgangs-Aufbereitungsbereiche 66 bzw. 68 für Datenenthalten, die von externen operativen Systemen 40 eingehenbzw. an diese abgehen.
[0070] Ineiner AusführungsformkönnenDaten in das MDM-System 4 von jeder entsprechenden Quellehereinkommen und das MDM-System 4 zu jedem entsprechendenZiel hin verlassen. Wenn im Kern-MDM-Referenzdatenspeicher gespeicherte Referenzdaten 22 externenoperativen Systemen 40 nicht leicht zur Verfügung gestelltwerden können, kannein Speichern von Referenzdaten 22 im Kern-MDM-Referenz-datenspeicherfür dasUnternehmen von geringem Wert sein. Umgekehrt kann es sein, dasssich andere Daten in Teilen des Unternehmens befinden, die durchdas MDM-System 4 an andere Teile des Unternehmens verteiltwerden müssen. 6 zeigt ein Beispiel für eine Architekturzur gemeinsamen Informationsnutzung 90 für das MDM-System 4.In einer Ausführungsformkann die Datenbank 36 fürVerwaltung von Referenzdaten 22 und nicht auf Geschwindigkeitder Dateneingabe oder Datenausgabe optimiert sein. Demnach kann eineAufbereitungsstrategie eingesetzt werden, um Datentransferzeitenin die externen operativen Systeme 40 und von diesen zuminimieren.
[0071] Wieoben beschrieben, könneneingehende Daten von einer oder mehreren Datenquellen 92 zur Speicherungim Kern-MDM-Referenzdatenspeicher des verwalteten Datenbereichs 72 empfangenwerden. Die Datenquellen 92 können persistente Datenspeichereinscließen,die externen Unternehmen 40a zugeordnet sind, wie zum BeispielHerstellern, Vertriebshändlern,Zulieferern und Kunden, wenn das MDM-System einem Beispiel-einzelhandelsunternehmenzugeordnet ist. Die Datenquellen 92 können auch operative Aufbereitungsdatenspeichereinscließen,die Planungs-, Durchführungs-, Überwachungs- oderanderen Unternehmenslösungskomponenten 6 zugeordnetsind. Die eingehenden Daten werden zuerst in Eingangsaufbereitungstabellen 94 desEingangsaufbereitungsbereichs 84, dann in Kern-MDM-Tabellen 96 imKern-MDM-Referenzdatenspeicherdes verwalteten Datenbereichs 72 als Referenzdaten 22 bewegt.Gegebenenfalls kann eine Daten-bereinigung, Validation, Transformation odereine andere Verarbeitung währendder Bewegung der Daten vom Eingangsaufbereitungsbereich 84 zum Kern-MDM-Referenz-datenspeicherdes verwalteten Datenbereichs 72 geschehen. Zum Beispiel kannes sehr wichtig sein, dass die im Kern-MDM-Referenzdatenspeichergespeicherten und externen operati-ven Systemen 40 zurVerfügunggestellten Referenzdaten 22 als sauber gelten, weshalbdie Datenbereinigung im Zusammenhang mit dem Laden eingehender Datensteht.
[0072] Wieoben beschrieben, könnenausgehende Daten an ein oder mehrere Datenziele 98 geliefert werden,wie zum Beispiel persistente Datenspeicher, die externen Unternehmen 40a zugeordnetsind, oder operative Aufbereitungsdatenspeicher, die Planungs-,Ausführungs-, Überwachungs-oder anderen externen Unternehmenslösungskomponenten 6 zugeordnetsind. Ausgehende Daten, die unter der Verwendung des MDM-Systems 4 ohneSpeicherung im Kern-MDM-Referenzdatenspeicher verteilt werden, können vonEingangsaufbereitungstabellen 94 des Eingangsaufbereitungsbereichs 84 anAusgangsaufbereitungstabellen 100a des entkoppelten Ausgangsaufbereitungsbereichs 86a unddann zu den Datenzielen 98 gesendet werden. In ähnlicherWeise könnenausgehende Referenzdaten 22 im Kern-MDM-Referenzdatenspeicherdes verwalteten Datenbereichs 72 aus den Kern-MDM-Tabellen 96 desverwalteten Datenbereichs 72 in Ausgangsaufbereitungstabellen 100b desgekoppelten Ausgangsaufbereitungsbereichs 86b und dannzu den Datenzielen 98 bewegt werden. Die Referenzdaten 22,die in den Kern-MDM-Tabellen 96 gespeichertsind, könnenim Wesentlichen ständigmit den Ausgangsdaten in den Ausgangs-aufbereitungstabellen 100 synchronisiertwerden, so dass zu einem beliebigen Zeitpunkt ein genauer Schnappschussder Referenzdaten 22 im Ausgangsaufbereitungsbereich 86 zurVerfügungsteht. Die Synchronisation der Referenzdaten mit den operativenDaten kann zum Beispiel wichtig sein, wenn sichergestellt werdensoll, dass eine auf den operativen Daten basierende Planung nichtfür eineEntitätdurchgeführtwird, die im von den Referenzdaten 22 wiedergegebenen Unternehmengar nicht mehr existiert. Eine Datentransformation oder eine andereVerarbeitung kann gegebenenfalls während der Bewegung der Referenzdaten 22 vom Kern-MDM-Referenzdatenspeicherdes verwalteten Datenbereichs 72 in den Ausgangsaufbereitungsbereich 86 geschehen.
[0073] Wiedergemäß 3 kann in einer Ausführungsformdie Dienststruktur 32 in die folgenden Gruppen, ohne Einschränkung, organisierteDienste 34 bereitstellen: (1) Geschäftsprozesswerkzeug 34a, (2)Sicherheitsdienste 34b, (3) allgemeine Dienste 34c,(4) Benutzerschnittstellendienste 34d, (5) Datenzugriffsdienste 34e und(6) Datenaufbereitungsdienste 34f.
[0074] DasGeschäftsprozesswerkzeug 34a kann unterder Verwendung eines entsprechenden Untersystems in der Dienststruktur 32 bereitgestelltwerden, das eine Verwaltung von MDM-Modellen, Prozessen und entsprechendenGeschäftsregelnleistet. Die diesem Untersystem zugeordneten automatisierten Prozessekönnenzum Durchführenvon Modellveränderungenin Zusammenhang mit dem physischen Einsatz des MDM-Systems 4 verwendetwerden. In einer Ausführungsformkann das Geschäftsprozesswerkzeug 34a,ohne Einschränkung,enthalten: (1) ein MDM-Studio (2) eine MDM-Modellbibliothek,(3) einen Geschäftsregelverwaltungsdienst,(4) einen Prozesscontroller und (5) einen MDM-Strukturaktualisierungsdienst.
[0075] 7 veranschaulicht ein Beispielfür ein MDM-Studio 110,eine zugeordnete MDM-Modellbibliothek 112, die ein odermehrere MDM-Modelle 114 enthält, die für das MDM-System 4 geeignetsind, und einen zugehörigenMDM-Datenthesaurus 116.
[0076] DasMDM-Studio 110 kann Dienste zum Modellieren der Strukturdes MDM-Systems 4 undseiner Komponenten bereitstellen, zum Beispiel zu Zwecken des Konstruierensdes MDM-Systems 4 oder zu Zwecken des Erweiterns oder sonstigen Aktualisierensdes MDM-Systems 4. Das MDM-Studio 110 kann eineUnterstützungfür eineoder mehrere grafische Modellierungsbenutzerschnittstellen bereitstellen.Eine Modellierung des MDM-Systems 4 kann zum Beispiel einModellieren struktureller Aspekte des Kern-MDM-Referenzdatenspeichersinnerhalb des verwalteten Datenbereichs 72 der Datenbank 36, einModellieren der Struktur der Aufbereitungsbereiche 66 und 68 derDatenbank 36 und ein Modellieren entsprechender Prozessarbeitsabläufe beinhalten. DasMDM-Studio 110 kann eine Unterstützung sowohl für die anfänglicheKonstruktion von MDM-Modellen 114 als auch eine spätere Erweiterungoder andere Aktualisierung der MDM-Modelle 114 bereitstellen.In einer Ausführungsformbeinhalten die MDM-Modelle 114, ohne Einschränkung: (1)ein MDM-Prozessmodell 114a, (2) ein MDM-Dokumentenmodell 114b,(3) ein MDM-Formularmodell 114c, (4) ein MDM-Referenzdatenmodell 114d und(5) ein MDM-Aufbereitungsdatenmodell 114e.
[0077] Prozessmodelle 114a beschreibendie Prozesse 14, die zum Verwalten der Referenzdaten 22, dieim Kern-MDM-Referenzdatenspeicher in der Datenbank 36 gespeichertsind, verwendet werden. In einer Ausführungsform beschreibt für einenbestimmten Prozess 14 das entsprechende Prozessmodell 114a denAblauf von Aufgaben, die im Zusammenhang mit dem Prozess 14 anden Referenzdaten 22 durchzuführen sind, mit diesen Aufgabenverbundene bestimmte Dienste 18, und eine oder mehrerebestimmte Prozessmaschinen (Process Engines), die für die Durchführung desProzesses 14 verantwortlich sind. Für dienstorientierte Aufgabenkönnendie Beschreibungen Web Services Description Language (WSDL)-Protokolleverwenden. Jeder Prozess 14 kann einen oder mehrere Benutzerschnittstellen-Aufgabenabläufe, Unternehmenslösungs-Komponenten-aufgabenabläufe, Inter-Unternehmens-Prozessabläufe oderbeliebige andere geeignete Prozesse oder Aufgabenabläufe repräsentieren.Das Prozessmodell 114a kann die Zuweisung eines jeden Prozesses 14 zueinem Process Controller, Benutzerschnittstellencontroller odereinem Arbeitsablaufcontroller auf Unternehmensebene festlegen. DasProzessmodell 114a kann auch grafische oder andere Simulationenvon Prozessen 14 liefern.
[0078] DasDokumentenmodell 114b liefert die Metadaten für MDM-Dokumente,die im Zusammenhang mit den Prozessen 14 verwendet werden.In einer AusführungsformrepräsentierenMDM-Dokumente externe cache-gespeicherte Darstellungen spezifischerMetadatenelemente innerhalb des darunter liegenden Referenzdatenmodells 114d.
[0079] DasFormularmodell 114c liefert Metadaten, welche Formulareim Zusammenhang mit Objekten innerhalb des Referenzdatenmodells 114d beschreiben.Formulare könnenzur effizienten Extraktion von Metadatenelementen aus dem Referenzdatenmodell 114d wichtigsein und könnenanalog zu Datenbanksichten sein.
[0080] DasReferenzdatenmodell 114d repräsentiert die Metadaten, dieReferenzdaten 22, die im Kern-MDM-Referenzdatenspeichergespeichert sind, beschreiben. Dies ist die Metadatendarstellungauf niedrigster Ebene, die in der Modellbibliothek 112 enthaltenist. In einer Ausführungsformkann das Referenzdatenmodell 114d ein Unternehmensmetamodellim Extensible Markup Language (XML) Description (XSD)-Formatsein,das Instanzdaten von Metadaten in einer Weise trennen kann, diefür die Verwaltungwünschenswertist, und die die back side – Datenzugriffsschicht 42b direktaus der Modellbibliothek 112 lesen kann. Es kann wichtigsein, die Veränderungenam Referenzdatenmodell 114d mit eventuellen Konstrukteneiner höherenEbene, wie zum Beispiel dem Formularmodell 114d oder dem Dokumentenmodell 114b,zu synchronisieren. Eine Synchronisation der Modelle 114 kannautomatisch geschehen, oder das Studio 110 kann gegebenenfallsden Bedarf nach Änderungenmarkieren und einen Administrator-Benutzer ausweisen, bei der Synchronisationder Modelle 114 mitzuwirken.
[0081] Eingenerisches Referenzdatenmodell für die Referenzdaten 22,die im Kern-MDM-Referenzdatenspeicherzu speichern sind, kann so konstruiert werden, dass es eine Synthesealler anwendbaren Datenelemente darstellt, wie zum Beispiel alleDatenelemente, die mit Unternehmen in der Einzelhandelsbranche zusammenhängen, undkann als eine übergeordneteMenge von Referenzdatenmodellen 114d betrachtet werden,die beim tatsächlichenEinsatz des MDM-Systems 4 verwendet werden. Das generischeReferenzdatenmodell und alle Referenzdatenmodelle 114d,die letztendlich aus dem generischen Referenzdatenmodell abgeleitetwerden, sollten in Hinblick auf Konsistenz und effiziente Verwaltungder Referenzdaten 22 konstruiert sein. In einer Ausführungsformkann das generische Referenzdatenmodell als ein Dokument in einemkommentierten RATIONAL ROSE-Objektmodell erfasst sein.
[0082] sDasAufbereitungsdatenmodell 114e repräsentiert Metadaten, welchedie Struktur der Eingangs- und Ausgangs-Aufbereitungstabellen 94 bzw. 78 beschreibensowie die Abbildung zwischen dem Referenzdatenmodell 114d undder Aufbereitungstabellendarstellung der Daten innerhalb der Eingangs- undAusgangs-Aufbereitungstabellen 94 bzw. 78. DasReferenzdatenmodell 114d kann ein normalisiertes Datenmodellsein, das, wie oben beschrieben, aus einem generischen Referenzdatenmodell abgeleitetwurde. Die eingehenden Daten könnenjedoch ein beliebiges Schema widerspiegeln, das mit dem Referenzdatenmodell 114d nichtkonsistent ist. FürEingangsdaten könnenentsprechende Abbildungen (d.h. Transformationen) des Referenzdatenmodells 114d aufQuelldatenmodelle, wie zum Beispiel ein Eingangs-Aufbereitungsdatenmodell 114e,das ein beliebiges Eingabedatenformat für ein externes operatives System 40 repräsentiert, durchgeführt werden,währendEingangsdaten im Kern-MDM-Referenzdatenspeicher gespeichert werden.In ähnlicherWeise kann es notwendig sein, dass ausgehende Daten zum Verbrauchals operative Daten entnormalisiert werden. Für ausgehende Daten können entsprechendeAbbildungen (d.h. Transformationen) eines Referenzdatenmodells 114d aufZieldatenmodelle, wie zum Beispiel ein Ausgangs-Aufbereitungsdatenmodell 114e,das ein flaches Ausgabedatenformat für ein externes operatives System 40 darstellt, durchgeführt werden,währenddie Referenzdaten aus dem Kern-MDM-Referenzdatenspeicher herausbewegtwerden.
[0083] DasMDM-Studio 110 kann Dienste zum Erzeugen, Aktualisierenund Anzeigen des MDM-Datenthesaurus 116 bereitstellen.In einer Ausführungsformkann das MDM-System 4 zum Verwalten von Referenzdaten 22 undzum Unterstützeneiner Datenintegration übereine Vielzahl von Unternehmenslösungskomponenten 6 hinwegverwendet werden, die heterogene Softwareumgebungen mit unterschiedlichenReferenzdatenmodellen 114d und zugehörenden Schemata darstellen.Der Datenthesaurus 116 erlaubt es dem MDM-System 4 vorzugsweise,solche vielfältigenheterogenen Unternehmenslösungskomponenten 6 unddie entsprechenden Modelle 114d in einer Weise aufzunehmen,die es dem Benutzer erlaubt, die Beziehungen zwischen Feldern inunterschiedlichen Schemata oder zwischen Feldern in unterschiedlichenDomäneninnerhalb eines bestimmen Schemas gemäß den entsprechenden Bedürfnissenzu definieren und zu betrachten.
[0084] 8 veranschaulicht ein Beispielvon Schemata fürReferenzdaten 22, die im MDM-System 4 gespeichertsind. In einer Ausführungsformunterstütztdas MDM-System 4 eine Vielzahl von Schemata 120,wobei jedes Schema 120 eines oder mehrere Referenzdatenmodelle 114d beinhaltet,die in Beziehung zueinander stehen können oder auch nicht. JedesModell 114d enthältein oder mehrere Felder 124, wobei ein bestimmtes Feld 124 zueinem oder mehreren Modellen 114d innerhalb eines bestimmtenSchemas 120 gehörenkann. Eine bestimmte Teilmenge von Feldern 124 innerhalbeines Modells 114d kann ein Untermodell des Modells 114d darstellen.Je nach den entsprechenden Feldern 124 können dieModelle 114d physische Geschäftsentitäten (z.B. Artikel, Standorte,Zulieferer, Kunden, Stücklistenusw.), logische Geschäftsbeziehungen(z.B. Artikel mit Standorten, Artikel mit Zulieferern, Standortemit Zulieferern, usw.), Geschäftsparameter(z.B. Bestandsparameter, logistische Information, Kalender usw.)oder eine beliebige andere geeignete Information definieren. Ineiner Ausführungsformist das Masterschema 122 die Vereinigung aller Modelle 114d innerhalbder Schemata 120, die fürden Betrieb des MDM- Systems 4 bezüglich seiner Verwaltung derReferenzdaten 22 und der Interaktion mit den Unternehmenslösungskomponenten 6 benötigt werden.Das Masterschema 122 liefert gemäß geeigneten Abbildungen zwischendem Masterreferenzdatenmodell und den Modellen 114d eingemeinsames oder anderes Masterreferenzdatenmodell über alleModelle 114d hinweg. Wo das MDM-System 4 zum Beispielzur Verwaltung von Referenzdaten 22 über heterogene Unternehmenslösungskomponenten 6 mitunterschiedlichen Modellen 114d hinweg verwendet wird,liefert das Masterschema 122 ein Masterreferenzdatenmodell,das alle diese Modelle 114d mit einschließt.
[0085] EinModell 114d kann in verschiedenster Weise innerhalb desKontexts eines bestimmten Schemas 120 erweitert werden.Wie in 9a gezeigt, wirdein Basismodell 114d in einem ersten Beispielverfahrendurch Hinzufügenvon neuen Erweiterungsfeldern 124 zu den schon im Basismodell 114d vorhandenenBasisfeldern 124 erweitert, zum Beispiel über eineBenutzerschnittstelle, die dem MDM-Studio 110 zugeordnetist. Bei diesem Verfahren wird das Basismodell 114d, demBasismodell 114d zugeordnete bestehende physische Tabellenstrukturenund bestehende Benutzerschnittstellen-Arbeitsabläufe, die vom Basismodell 114d abhängen, beibehalten.Alle Felder 124, einschließlich der Basisfelder 124 undder neuen Erweiterungsfelder 124, werden dem Benutzer über diebestehenden Benutzerschnittstellen-Arbeitsabläufe dargeboten. Alternativdazu wird, wie in 9b dargestellt,ein Basismodell 114d in einem zweiten Verfahren durch dieSchaffung eines neuen erweiterten Modells 114d erweitert,das alle Basisfelder 124 vom Basismodell 114d erbt.Bei diesem Verfahren bleiben die bestehenden physischen Tabellenstrukturenund die Benutzerschnittstellen-Arbeitsabläufe für das Basismodell 114 nichterhalten. Stattdessen wird eine neue physische Tabelle mit dem Namendes neuen erweiterten Modells 114d in der physischen Instantiierung desneuen erweiterten Modells 114d geschaffen. Bei der vorliegendenErfindung wird die Erweiterung eines Modells 114d in einerbeliebigen Weise in Betracht gezogen. Eine Erweiterung von Modellen 114d innerhalbdes MDM-Systems 4 kann gegebenenfalls auf bestimmte Rolleninnerhalb eines zugeordneten Unternehmens eingeschränkt sein.
[0086] 10 veranschaulicht Beispieldatenverzeichnissefür dieSchemata innerhalb des MDM-Systems 4. Eine Liste allerFelder 124 innerhalb eines Schemas 120 definiertein Datenverzeichnis 126 für das Schema 120.In einer Ausführungsformenthältein Masterdatenverzeichnis 128 für das MDM-System 4 eineListe aller Felder 124 für alle Modelle 114d innerhalbdes Masterschemas 122. Das Masterdatenverzeichnis 128 kannalphabetisch nach dem Feld 124 angezeigt werden. In diesemFall wird fürjedes Feld 124 eine Liste von Modellen 114d, indenen das Feld 124 verwendet wird, alphabetisch nach demModellnamen unter, neben oder anders im Zusammenhang mit dem Feld 124 angezeigt,wobei ein Modell 114d fürmehrere Felder 124 in den Modelllisten erscheinen kann.Alternativ dazu kann das Masterdatenverzeichnis 128 alphabetischnach Modellnamen angezeigt werden. In diesem Fall kann für jedesModell 114d eine Liste von Feldern 124 innerhalbdes Modells 114d alphabetisch unter, neben oder andersim Zusammenhang mit dem Modell 114d angezeigt werden, wobeiein Feld 124 fürmehrere Modelle 114d in den Feldlisten erscheinen kann.
[0087] Wenninnerhalb des MDM-Systems 4 ein neues Modell 114d hinzugefügt wird,kann das Masterdatenlexikon 128 als Basis zur Schaffungdes neuen Modells 114d verwendet werden. Wenn ein oder mehrereneue Felder 124 fürdas neue Modell 114d benötigt werden, die derzeit nochnicht im Masterdatenlexikon 128 bestehen, dann wird ineinem Verfahren zuerst das Masterdatenlexikon 128 mit denneuen Feldern 124 aktualisiert und dann das neue Modell 114d aufder Grundlage des aktualisierten Masterdatenlexikons 128 erzeugt.In einem anderen Verfahren wird das neue Modell 114d zuerstunter Einbeziehung der neuen Felder 124 erzeugt, und dannwird ein aktualisiertes Masterdatenlexikon 128 automatischentsprechend generiert. Bei der vorliegenden Erfindung wird einSynchronisieren des Masterdatenlexikons 128 mit allen Modellen 122 undihren entsprechenden Feldern 124 in jeder beliebigen geeignetenArt und Weise je nach den bestimmten Bedürfnissen in Betracht gezogen.
[0088] 11 zeigt Beispieldomänen für die Schematainnerhalb des MDM-Systems 4. Eine oder mehrere Domänen 130 können einemSchema 120 zugeordnet sein. Die Domänen 130 können Geschäftsfunktionen(z.B. Lieferkettenverwaltung, Kundenpartnerverwaltung, Einkommensoptimierungusw.), Branchen (z.B. High-Tech, Halbleiter, Einzelhandel usw.), Firmen(z.B. Celestica, Philips, Best Buy usw.) oder jede andere geeigneteInformation definieren. Jede Domäne 130 enthält ein odermehrere Felder 124, wobei ein bestimmtes Feld 124 zueiner oder mehreren Domänen 130 innerhalbeines bestimmten Schemas 120 gehören kann. Eine bestimmte Teilmenge vonFeldern 124 innerhalb einer Domäne 130 kann eine Unterdomäne der Domäne 130 repräsentieren. Ineiner Ausführungsformkann eine Masterdomäne 132 dieVereinigung aller Domänen 130 unddaher die Vereinigung aller Modelle 114d und ihrer entsprechendenFelder 124 überalle Schemata 120 innerhalb des MDM-Systems 4 hinwegeinschließen.Die Domänen 130 können aufder Ebene des Datenverzeichnisses statt auf der Ebene des Modellsspezifiziert sein. Zum Beispiel kann ein Feld 124 in einem Artikel-Modell 114d ineiner ersten Domäne 130 einenlogischen Namen item_id und in einer zweiten Domäne 130 einen logischenNamen part_id haben. Innerhalb eines Schemas 120 können dieModelle 114d Domänen 130 inder Weise zugeordnet sein, dass das Weglassen einer bestimmten Domäne 130 auchden Wegfall aller entsprechenden Felder 124 (d.h. der Felder 124 für alle Modelle 114d oderUntermodelle, die der bestimmten Domäne 130 zugeordnetsind) aus dem Schema 120 nach sich zieht.
[0089] Ineiner Ausführungsformgehörenstandardmäßig alleFelder 124, die unter der Verwendung von MDM-Studio 110 hinzugefügt werden,zur Masterdomäne 132.Es besteht eine Anzahl möglicherArbeitsabläufezum Zuweisen von Feldern 124 zu bestimmten Domänen 130.Zum Beispiel kann der Benutzer in einem ersten Anwendungsfall neueFelder 124 hinzufügen,um ein bestehendes Modell 114d zu erweitern, die neuenFelder 124 könnendem Datenverzeichnis 126 für das Schema 120,das dem Modell 114d zugeordnet ist, automatisch oder andershinzugefügtwerden, und der Benutzer kann fürjedes neue Feld 124 die bestimmte Domäne 130 einstellen.Die neuen Felder 124 könnengegebenenfalls als Gruppe zugewiesen werden. Als ein weiteres Beispielkann der Benutzer in einem zweiten Anwendungsfall ein neues Modell 114d mitneuen Feldern 124 schaffen, die neuen Felder 124 können demDatenverzeichnis 126 fürdas Schema 120, das dem neuen Modell 114d zugeordnetist, automatisch oder anders hinzugefügt werden, und der Benutzerkann fürjedes neue Feld 124 die bestimmte Domäne 130 einstellen.Die neuen Felder 124 könnengegebenenfalls als Gruppe zugewiesen werden. Als ein weiteres Beispielkann ein Benutzer in einem dritten Anwendungsfall für die bestimmteDomäne 130 einenDomänennameneingeben, die neuen Felder 124 dem Datenverzeichnis 126 für das Schema 120,das der bestimmten Domäne 130 zugeordnetist, hinzufügen,ein neues Modell 114d unter der Verwendung des Datenverzeichnisses 126 erzeugenund die neuen Felder 124 dem neuen Modell 114d automatischoder anders hinzufügen.Bei der vorliegenden Erfindung wird das Zuweisen von Feldern 124 zubestimmten Domänen 130 in einerbeliebigen geeigneten Art und Weise in Betracht gezogen.
[0090] 12 zeigt einen Beispieldatenthesaurus 116,der Abbildungen und entsprechende Synonyme über viele, vorzugsweise alle,Schemata 120 liefert. Zum Beispiel können unterschiedliche SAP-und Siebel-Schemata 120 bestehen, mit bestimmten Abbildungenzwischen den beiden Schemata 120. In einer Ausführungsformkann das MDM-System 4 die beiden Schemata 120 indas MDM-Studio 110 laden und für jedes Feld 124 imMasterdatenverzeichnis 128 für das Masterschema 122 einenSynonymsatz 134 für dieentsprechenden Felder 124 in den beiden Schemata 120 erzeugen.Dadurch, dass dem Masterdatenverzeichnis 128 und dem Datenthesaurus 116 seineAbbildungen und entsprechende Synonyme 134 zwischen demMasterdatenverzeichnis 128 und den Datenverzeichnissen 126 für andereSchemata 120 geliefert werden, wird es vorzugsweise möglich, dass beliebigegeeignete heterogene Unternehmenslösungskomponenten 6 undentsprechende externe operative Systeme 40 vom System 2 leichtangenommen und integriert werden.
[0091] DerDatenthesaurus 116 kann einem Benutzer unter Bezugnahmeauf das Masterschema 122 angezeigt werden. In diesem Fallkann der Datenthesaurus 116 so angezeigt werden, dass alleFelder 124 im Masterdatenverzeichnis 128 für das Masterschema 122 unddie entsprechenden Synonyme 134 in einem, einigen oderallen Schemata 120, wie zum Beispiel dem SAP- und dem Siebel-Schema 120 gezeigtwerden. Stattdessen oder zusätzlichhierzu kann der Datenthesaurus 116 einem Benutzer bezüglich einigeroder aller Schemata 120 ohne das Masterschema 122 angezeigtwerden. In diesem Fall kann eines der Schemata 120 (z.B.das SAP-Schema 120) entweder durch Standardeinstellungoder gemäß einerBenutzereingabe als das Hauptschema (Root Schema) 120 bezeichnetwerden. Der Datenthesaurus 116 kann unter Anzeige allerFelder 124 im Datenverzeichnis 126 für das Hauptschema 120 und ihreentsprechenden Synonyme 134 in einem, manchen oder allenSchemata 120 (z.B. dem Siebel-Schema 120) angezeigtwerden. Auch wenn die Synonyme 134 und die entsprechendenAbbildungen fürzwei Schemata 120 in 12 alsBeispiel gezeigt sind, wird bei der vorliegenden Erfindung in Betracht gezogen,dass der Datenthesaurus 116 Synonyme 134 für eine beliebigeAnzahl von Schemata 120 enthält.
[0092] 13 zeigt einen Beispieldatenthesaurus 116,der Abbildungen und entsprechende Synonyme 134 über eineVielzahl, vorzugsweise alle, Domänen 130 ineinem Schema 120 hinweg bereitstellt. Der Datenthesaurus 116 kanndiese Abbildungen und die entsprechenden Synonyme 134 anstellevon oder zusätzlichzu denjenigen bereitstellen, die oben unter Bezugnahme auf 12 beschrieben wurden. Wiein 13 gezeigt, kannauf die Felder 124 innerhalb des Datenverzeichnisses 126 für das Schema 120 unterVerwendung eines anderen logischen Namens in jeder Domäne 130 Bezuggenommen werden. Zum Beispiel kann ein item_identifier-Feld im Datenverzeichnis 126 ineiner ersten Domäne 130 als item_idund in einer zweiten Domäne 130 alspart_id bezeichnet werden. In einer Ausführungsform kann der Datenthesaurus 116 bezüglich einerHauptdomäne 130,die entweder standardmäßig odergemäß einerBenutzereingabe bestimmt wurde, angezeigt werden. Als ein Beispielkann ein Benutzer den Namen einer Domäne 130 eingeben, für die derDatenthesaurus 116 gewünschtwird. Diese kann als die Hauptdomäne 130 bestimmt werden.Der Benutzer kann dann die Liste einer oder mehrerer Domänen 130 eingeben,für welcheSynonyme 134 gewünscht werden.In Reaktion auf diese Benutzereingabe können für jedes Feld 124 derHauptdomäne 130 Synonyme 134 für eine,einige oder alle anderen Domänen 130,die dem Schema 120 zugeordnet sind, angezeigt werden.
[0093] Wiedermit Bezug auf 3 kannder Geschäftsregeln-Verwaltungsdienstzur Schaffung und Pflege von Geschäftsregelelementen dienen, dieden Diensten 18 zugeordnet sind, wie zum Beispiel Importvalidationsregeln,Aufbereitungs-Transformationsregeln und allgemeine Konsistenzregeln,die dem MDM-System 4 zugeordnet sind. Der Geschäftsregeln-Verwaltungsdienstkann laufzeitscriptbasierte Regeln oder eine Zuordnung von Konstruktionszeitregelobjektenzu MDM-Prozess-Arbeitsabläufenbereitstellen.
[0094] DerProzess-Controller kann einen Laufzeit-Prozess-Arbeitsablaufcontrollerfür das MDM-System 4 repräsentieren.Wie oben beschrieben, kann das Prozessmodell 114a eineZuweisung von einem oder mehreren Prozessen 14 zu dem Prozess-Controller,einem Benutzerschnittstellencontroller oder einem Arbeitsablaufcontrollerauf Unternehmens ebene spezifizieren. In einer Ausführungsform arbeitetder Prozess-Controller in Zusammenarbeit mit einem beliebigen solchenBenutzerschnittstellen-controller und einem beliebigen solchen Arbeitsablaufcontrollerauf Unternehmensebene.
[0095] Ineiner Ausführungsformstellt das MDM-System 4 einen Mechanismus zum Modellierenseiner Struktur und einen Mechanismus zum Automatisieren eines Prozesseszum Realisieren einer Erweiterung dieses Modells in einem physischenEinsatzfall bereit. Der Struktur-Aktualisierungsdienst kann eineautomatisierte Implementierung eines Modells 114 liefern,das währenddes Modellierungsprozesses geschaffen oder verändert wird. Der Struktur-Aktualisierungsdienstkann insbesondere im Zusammenhang mit der Struktur der Eingangs-und Ausgangs-Aufbereitungsbereiche 66 bzw. 68 wichtig sein.Es kann notwendig sein, anfänglichdas Aufbereitungsdatenmodell 114e, das Referenzmodell für die Aufbereitungsbereichstruktur,zu spezifizieren. Außerdemkann es notwendig sein, entsprechende Structured Query Language(SQL) oder Veränderungenan der SQL zu generieren, um den Zustand der Aufbereitungsbereiche 66 und 68 imVerhältniszum Aufbereitungsdatenmodell 114e aufrecht zu erhalten. OhneAutomatisierung dieser Aufgaben unter Verwendung des Struktur-Aktualisierungsdiensteswäre dieAufrechterhaltung einer Koordination verschiedenster Elemente desMDM-Systems 4 eine sehr arbeitsintensive manuelle Aufgabe.Der Strukturaktualisierungsdienst kann auch das Aufbereitungsdatenmodell 114e undandere Modelle 114 zusammen mit der entsprechenden SQLin Reaktion auf Aktualisierungen, die mit Unternehmenslösungskomponenten 6 geliefertwerden, aktualisieren. Diese Strukturaktualisierungen können gemäß Aktualisierungsbeschreibungs-Skriptdokumentendurchgeführtwerden, welche die fürdie automatische Durchführung derStrukturaktualisierung notwendige Information liefern.
[0096] Natürlich solltees nur Benutzern mit entsprechender Zugangsberechtigung erlaubtwerden, die Referenzdaten 22 im MDM-System 4 zu betrachten oderzu manipulieren. Sicherheitsdienste 34b können unterder Verwendung eines entsprechenden Untersystems innerhalb der Dienststruktur 32,das zum Erfüllenvon zwei Hauptaufgaben konstruiert wurde, vorgesehen werden. Dieerste Aufgabe besteht darin, den Zugang zum MDM-System 4 selbst zu kontrollieren.Die zweite Aufgabe besteht darin, die Struktur des Sicherheitsmodellsbei seiner Anwendung auf die Unternehmenslösungskomponenten 6 zuverwalten. Fürdiese Aufgabe sind Dienste zum Verwalten des Sicherheitskontextsvorgesehen, die alle Unternehmenslösungskomponenten 6 verwenden,zum Beispiel durch einen LDAP-Speicher, dessen Masterkopie 82 sichinnerhalb des operativen Zugriffsbereichs 80 der Datenbank 36 befindet.Die Sicherheitsdienste 34b können ohne Einschränkung beinhalten:(1) Authentifizierungsdienste und (2) Autorisierungsdienste.
[0097] Authentifizierungsdiensteliefern eine anfänglicheLog-In-Sicherheit bezüglichUnternehmenslösungskomponenten 6.Die Authentifizierung basiert vorzugsweise auf einem Organisationsmodell für das Unternehmen,um einen einzigen Log-In-Sicherheitskontext für alle Unternehmenslösungskomponenten 6 bereitzustellen.
[0098] DieAutorisierungsdienste stellen einen schichtweisen, granularen Zugriffauf bestimmte Dienste 18 oder Referenzdaten 22 für einenauthentifizierten Benutzer bereit. Die Autorisierung kann auf zweiEbenen erfolgen. Die erste Ebene (Ebene 1) befasst sich mit demZugriff auf Unternehmenslösungskomponenten 6,die durch spezifische Anwendungen oder Gruppen von Diensten 18 repräsentiertwerden. Die zweite Ebene (Ebene 2) beschäftigt sich mit dem Zugriffauf spezifische Funktionen innerhalb einer Unternehmenslösungskomponente 6.Die Autorisation auf Feldebene kann gegebenenfalls auch durch bestimmteUnternehmenslösungskomponenten 6 selbstdurchgeführtwerden. In dem Fall des MDM-Systems 4 selbst kann es notwendigwerden, eine Autorisierung oberhalb der Ebene 2 (d.h. Ebene 3 oderhöher)innerhalb des MDM-Systems 4 vorzusehen.
[0099] AllgemeineDienste 34c könnenunter der Verwendung eines entsprechenden Untersystems innerhalbder Dienststruktur 32 vorgesehen werden und können, ohneEinschränkung,enthalten: (1) einen Änderungsverwaltungsdienst;(2) einen Lebenszyklusverwaltungsdienst; (3) einen Gruppenverwaltungsdienstund (4) einen Analyse- und Berichtsdienst.
[0100] Die Änderungsverwaltungsdienstestellen ein Protokoll fürim MDM-System 4 vorgenommene Änderungen bereit. Zum Beispielkann Information darüberaufbewahrt werden, wer eine Änderung durchgeführt hat,zu welcher Zeit die Änderunggemacht wurde und vielleicht überden geänderten Wert.Das Protokoll für Änderungensollte vorzugsweise in einer solchen Weise implementiert sein, dassder Mechanismus fürInformationen, die keine Änderungsverwaltungbenötigen,oder für Änderungenvor der Konfigurationssteuerung, wie zum Beispiel Änderungenim Zusammenhang mit der anflänglichenEinrichtung von Datenelementen, abgeschaltet werden kann. Eine logischeGruppierung von Referenzdaten 22 kann für viele Datenverwaltungsaspektewichtig sein, wie zum Beispiel das Abrufen von Referenzdaten 22 unddie Durchführung von Änderungenan Referenzdaten 22. Daher ist in einer Ausführungsformdie Änderungsverwaltungbezüglichder Granularitätgruppenbasiert, wobei eine Außerkraftsetzungauf der Gruppenmitgliedsebene stattfinden kann.
[0101] Wieoben beschrieben, haben die Referenzdaten 22, die im MDM-System 4 gespeichertsind, einen mit ihrer Verwendung konsistenten zugewiesenen Status.Der Lebenszyklusverwaltungsdienst erlaubt eine Definition einesLebenszyklus, der die möglichenZuständeder Datenelemente beschreibt, sowie einen Mechanismus zum Verwaltender Bewegung von Daten von einem Lebenszykluszustand zu einem anderen.
[0102] Angesichtsdes enormen Umfangs und des Maßstabsvon Daten, die potenziell im MDM-System 4 enthalten seinkönnen,wird es vorgezogen, dass die Gesamtstrategie für die Datenverwaltung auf logischenDatengruppen und nicht auf einzelnen Datenelementen basiert. Dielogische Gruppierung der Referenzdaten 22 kann für vieleDatenverwaltungsaspekte wichtig sein, wie zum Beispiel das Abrufender Referenzdaten 22 und die Durchführung von Änderungen an den Referenzdaten 22.Auch wenn einzelne Entitätenmanipuliert werden können,werden viele Aktualisierungen typischer-weise an Gruppen von Entitäten durchgeführt werden.In einer Ausführungsformist der Gruppenaspekt der Datenmanipulation von Grund auf im MDM-System 4 eingebaut.
[0103] DieGesundheit und der Status eines großen Datenspeichers, wie zumBeispiel des Kern-MDM-Referenzdatenspeichers in der Datenbank 36 istentscheidend. Der Analyse- undBerichtsdienst liefert Kenntnis darüber, welche Referenzdaten 22 imKern-MDM-Referenzdatenspeichergespeichert sind, sowie überden Status der verschienenen Systemelemente des MDM-Systems 4.Auch wenn die Typen der Analyse und der entsprechenden Berichtefür einMDM-System 4 spezifisch sein werden, können allgemeine Analyse- undBerichtswerkzeuge gegebenenfalls eingesetzt werden. Die Analysekann sich auf ein breites Spektrum von Aktivitäten erstrecken, die direktdurch diesen Dienst oder indirekt durch die Verwaltung durch diesenDienst unterstützt werden.Die Analyse kann ein Clustering von Diensten für Attribute/Merkmale, Entscheidungsunterstützungsaktivitäten bezüglich imKern-MDM-Referenzdatenspeicher gespeicherter Entitätsdaten,die Verwaltung einer Parameterberechnung, wie zum Beispiel eineKoordinierungsparameterberechnung unter der Verwendung einer externenMaschine, die Aktualisierung von Parametern, wie zum Beispiel Vorlaufzeitenfür Artikelan bestimmten Standorten, und beliebige andere geeignete Analyseneinschließen. DieBerichte können Änderungs-Protokoll-Aktivität, Historienspurenfür spezifischeEntitätenoder Gruppen von Entitäten,Berichte überProduktionsparametersätze,einschließlichZeitphasensätze,Kalenderprüfungund -abstimmung, Berichte überneue Entitäten(wie zum Beispiel neue Artikel), die in den Kern-MDM-Referenzdatenspeichereingegeben wurden, und tote Entitäten (zum Beispiel Artikel),die aus dem Kern-MDM-Referenzdatenspeicher entfernt wurden, undbeliebige andere geeignete Berichte einschließen.
[0104] DieDatenzugriffsdienste 34e können unter der Verwendung einesentsprechenden Untersystems innerhalb der Dienststruktur 32 zumLiefern einer Schlüsselschnittstellezwischen Benutzerschnittstellenschichten, Datenverwaltungsgeschäftsregeln unddem darunter liegenden Kern-MDM-Referenzdatenspeicher innerhalbder Datenbank 36 bereitgestellt werden. Die Datenzugriffsdienste 34e können innerhalbder oben anhand von 5 beschriebenen Datenverwaltungsstruktur 78 enthaltensein. Da in einer Ausführungsformdie vorherrschende Sicht der Referenzdaten 22 objektbasiertist, könnendie Datenzugriffsdienste 34e eine persistente Abbildungauf darunter liegende Datenstrukturen innerhalb der Datenbank 36 unterstützen. Demnachkönnenin einer Ausführungsformdie Datenzugriffsdienste 34e das Konzept eines Datencaches,wie zum Beispiel des cache-gespeicherten Datenbereichs 74 derDatenbank 36, der oben beschrieben wurde, beinhalten, dereinen Mechanismus zum Halten einer Kopie der Referenzdaten 22 imcache-gespeicherten Datenbereich 74 zur Manipulation vorsieht,währendder Zustand der Referenzdaten 22 im Kern-MDM-Referenzdatenspeicherdes verwalteten Datenbereichs 72 in einem Nur-Lese-Zustandgesperrt bleibt, bis der Manipulationsprozess abgeschlossen ist.Nachdem eine Kopie der Referenzdaten 22 als cache-gespeicherte Daten 76 imcachegespeicherten Datenbereich 74 während des Manipulationsprozessesgehalten wird, sieht der Manipulationsprozess nur den Zustand der cache-gespeichertenDaten 76 innerhalb des cache-gespeicherten Datenbereichs 74,währendandere Prozesse, Dienste und Systeme, die dem MDM-System 4 zugeordnetsind, den wahren Zustand der Referenzdaten 22 innerhalbdes verwalteten Datenbereichs 72 und nicht einen Zwischenzustandsehen, der den immer noch unvollständigen Manipulationsvorgangwiderspiegelt. Die Datenzugriffsdienste 34e können, ohneEinschränkung,enthalten: (1) einen Persistenzverwaltungsdienst; und (2) einenDatenzugriffsschichtdienst.
[0105] DerPersistenzverwaltungsdienst liefert die logische Abbildung zwischender Benutzersicht der Referenzdaten 22 und dem darunterliegenden persistenten Objektmodell, das den Referenzdaten 22 zugeordnetist. Der Dienst stellt die Verwaltung der Schaffung, der Aktualisierungund der Löschungvon Modellinstanzen, einschließlicheines entsprechenden Cache-Speicherns von persistenten Objekten aufSpeicherebene bereit.
[0106] DerDatenzugriffsschichtdienst stellt die Verbindung zwischen dem denReferenzdaten 22 zugeordneten logischen Objektmodell undden physischen Instanzen der relationalen Kern-MDM-Tabellen 96 bereit,in denen die persistenten Objekte als Referenzdaten 22 enthaltensind. Die Trennung der Persistenzschicht von einer bestimmten physischen Abbildungsschichterlaubt eine Vielzahl physischer Ziele, was insbesondere dann nützlich ist,wenn ein verteiltes physisches Datenmodell nötig ist (z.B. in manchen Fällen derParameterpflege).
[0107] Datenaufbereitungsdienste 34e können unterVerwendung eines entsprechenden Untersystems innerhalb der Dienststruktur 32 hauptsächlich zum Leisteneiner Synchronisation der Eingangs- und Ausgangs-Aufbereitungsbereiche 66 bzw. 68 beim verwaltetenDatenbereich 72 der Datenbank 36 vorgesehen werden.Die Datenaufbereitungsdienste 34e können, ohne Einschränkung, enthalten:(1) einen Datenimportdienst; (2) einen Validierungsdienst; und (3)einen Syndizierungsdienst.
[0108] DerDatenimportdienst bietet Funktionen zum Bewegen von Daten von externenQuellen in die Datenbank 36. Zum Beispiel könnte derDatenimportdienst zum Bewegen bestehender Masterdaten in die Datenbank 36 zumSpeichern und zur späterenVerteilung an eine oder mehrere Planungs-, Ausführungs-, Überwachungs- oder andere Unternehmenslösungskomponenten 6 verwendetwerden. Das Importieren von Daten beinhaltet zum Beispiel das Bewegender Eingangsdaten in den Eingangs-Aufbereitungsbereich 84,gegebenenfalls das Validieren und das Transformieren der Eingangsdaten,und das Bewegen der Eingangsdaten vom Eingangs-Aufbereitungsbereich 48 inden Kern-MDM-Referenzdatenspeicherdes verwalteten Datenbereichs 72 als Referenzdaten 22.
[0109] DerValidationsdienst erlaubt es, dass vordefinierte und auch benutzerdefinierteValidationsregeln auf Eingangsdaten angewendet werden, bevor siein die Datenbank 36 eingefügt werden. Die Validationsregelnkönnengrundlegende Werteregeln, referentielle Integritätsregeln, unternehmensspezifische Geschäftsregelnoder beliebige andere geeignete Regeln sein. In einer Ausführungsformist die Validation so auswählbar,dass höhereEbenen einer Validation verwendet werden können, wenn ein eingehenderDatensatz "schmutzig" ist, wofür eine strengereValidation benötigtwird, und niedrige Ebenen der Validation verwendet werden können, wennein eingehender Datensatz "sauber" ist, wofür eine wenigerstrenge Validation nötigist.
[0110] DerSyndizierungsdienst, der im Wesentlichen Daten aus der Datenbank 36 anPlanungs-, Ausführungs-, Überwachungs-oder andere Unternehmenslösungskomponenten 6 exportiert,kann zwei Hauptelemente enthalten. Das erste Element liefert Funktionenzur Synchronisierung von Kern-MDM-Tabellen 96 innerhalbdes verwalteten Datenbereichs 72 mit Ausgangs-Aufbereitungstabellen 100 innerhalbdes Ausgangs-Aufbereitungsbereichs 86, so dass ein gültiger Schnappschussder Referenzdaten 22 zu allen Zeiten in den Ausgangs-Aufbereitungstabellen 100 existiert,der mit Aktualisierungstransaktionsgrenzen konsistent ist. Das zweiteElement liefert Funktionen fürzeitplanungsbasierte oder nachfragebasierte Bewegungen von Datenvon Ausgangs-Aufbereitungstabellen 100 zu einer Zielunternehmenslösungskomponente 6.
[0111] 14 zeigt ein Beispiel einesMDM-Nutzungsmodells 130 für das MDM-System 4.Allgemein beschreibt das Nutzungsmodell 130, wie das MDM-System 4 inBezug darauf verwendet wird, wo die Daten gespeichert sind und wieauf die Daten zugegriffen wird. In einer Ausführungsform sehen die externenoperativen Systeme 40, die mit dem MDM-System 4 interagieren, dasMDM-System 4 als einen Referenzdatenspeicher und nichtals eine operative Datenquelle. Demnach können die Referenzdaten 22 innerhalbdes Kern-MDM-Referenzdatenspeichers 132 mitlokalen persistenten Speichern 134 externer operativerSysteme 40 durch entsprechende externe Zugriffsdienste 136,die im Zusammenhang mit einer oder beiden Datenzugriffsschichten 42 betriebenwerden, synchronisiert und an diese repliziert werden. Die internenZugriffsdienste 138 im Zusammenhang mit der Verwaltungder Referenzdaten 22 im MDM-System 4 können einendirekten Zugriff auf die Referenzdaten 22 im Kern-MDM-Referenzdatenspeicher 132 haben.Im Gegensatz dazu könnendie operativen Dienste 140 der externen operativen Systeme 40 dienicht mit der Verwaltung der Referenzdaten 22 im MDM-System 4 zusammenhängen, nurauf die Daten in den zugeordneten persistenten Speichern 134 zugreifen,sie greifen nie direkt auf die Referenzdaten 22 im Kern-MDM-Referenzdatenspeicher 132 zu.Auf diese Weise kann das MDM-System 4 im Wesentlichen alsein sicheres Aufzeichnungssystem arbeiten, dessen Architektur undKonstruktion zur Verwaltung von Referenzdaten 22 und nichtfür dieoperative Verwendung der Referenzdaten 22 optimiert sind.Verbrauchenden Diensten, außerdenjenigen, die im Zusammenhang mit der Verwaltung der Referenzdaten 22 stehen,ist kein direkter Zugriff auf die Referenzdaten 22 erlaubt.
[0112] Ineiner AusführungsformkönnenSchlüsselgrößen, diebei der Konstruktion einer physischen Architektur im Zusammenhangmit dem Nutzungsmodell 130 zu berücksichtigen sind, Folgendes,ohne Einschränkung,einschließen:(1) Durchsatzperformance; (2) Abfrageperformance; (3) Konfigurationsflexibilität; und (4)Skalierbarkeit. Jede dieser Größen wirdim Folgenden anhand entsprechender physischer Charakteristiken einerImplementierung eines MDM-Systems 4 erörtert.
[0113] DasHauptnutzungsmodell fürdas MDM-System 4 hat einen zentralen Masterspeicher, denKern-MDM-Referenzdatenspeicher 132 für den verwalteten Datenbereich 72 derDatenbank 36, für dieKernunternehmensdaten, die Referenzdaten 22. In einer Ausführungsformist ein Ziel die Abschirmung des Kern-MDM-Referenzdatenspeichers 132 gegenüber demoperativen Laden, währendeine optimale Konstruktion der externen operativen Systemen 40, welchedie Referenzdaten 22 in einem operativen Modus nutzen,ermöglichtwird. Demnach erfordert, wie oben eingehender beschrieben, das Nutzungsmodell 130 einSynchronisieren und Replizieren von Referenzdaten 22 inlokale persistente Speicher 134 der externen operativenSysteme 40, welche die Referenzdaten 22 benutzen.Dies setzt eine physische Architektur und eine Konstruktion voraus,welche eine Ausgangs-Durchsatzperformance zum Bewegen von Referenzdaten 22 vomKern-MDM-Referenzdatenspeicher 132 zu persistenten Zielspeichern 134 erleichtert.Wenn die Referenzdaten 22 in großen Mengen von externen operativenSystemen 40 in das MDM-System 4 bewegt werden,dann sollte die physische Architektur und die Konstruktion vorzugsweiseauch eine Eingangs-Durchsatzperformance unterstützen. Ein aus dem Obigen folgendes Hauptkonstruktions-kriteriumbesteht darin, dass die physische Datenschicht 54 einenso effizienten Zugriff auf die Referenzdaten 22 wie möglich bietensollte. Es kann daher wünschenswertsein, eine Indirektionsschicht in Betracht zu ziehen, die sich zwischen dendie Referenzdaten 22 enthaltenden Kern-MDM-Tabellen 96,die eine relationale Tabellenstruktur haben können, und der äußeren Darstellung vonReferenzdaten 22, die eine Objektdarstellung sein kann,befindet.
[0114] DerKontext fürdie Abfrageperformance besteht in der Konstruktion von Sichten derReferenzdaten 22 fürdie MDM-Benutzerschnittstelle oder einen Analysedienst innerhalbdes MDM-Systems 4, zum Beispiel den oben anhand von 3 beschriebenen Analyse-und Berichtsdienst. Es ist wahrscheinlich, dass diese Benutzerschnittstellen-und Analysedienstabfragen eher filtergesteuert sind, wobei nachbestimmten Untergruppen von Referenzdaten 22 in einem vielgrößeren Zeilenkontextgesucht wird als eine beliebige SQL oder andere Abfrage im Zusammenhangmit dem Massenexport von Referenzdaten 22, der oben anhanddes Durchsatzes erörtertwurde. Die Struktur der physischen Datenschicht 54 unddes entsprechenden Datenzugriffsschichtdienstes sollten so konstruiertsein, dass potenziell großeAnzahlen komplexer Abfragen in vertretbarer Zeit abgearbeitet werdenkönnen.Die Rückgabegroßerund kleiner Abfrageergebnis-Zeilensätze sollte unabhängig vomZieldienst (z.B. der Benutzerschnittstelle) effizient sein. Konstruktionskriterien für die Abfrageperformancekönnenkurze durchschnittliche Abfragereaktionszeiten auf der Datenbankebene,ausreichende Performance beim Eingangsladen mit einer großen Anzahlvon Eingangsabfragen und eine minimale Latenz beim zugeordnetenDatenzugriffsschichtdienst sein.
[0115] DieKonfigurationsflexibilitätkann sowohl aus Sicht des Benutzers als auch aus Sicht der Lösung untersuchtwerden. Aus Benutzersicht müssen dieim Kern-MDM-Referenzdatenspeicher 132 gespeichertenReferenzdaten 22 auf eine bestimmte Datensicht abgebildetwerden, die das Unternehmen benötigt.Aus Lösungssicht,bei der die Kerngrößen typischerweisedie Performance bei der Replikation und die Abfrageperformance sind,kann es sein, dass die Konfigurationsflexibilität weniger entscheidend, wennnicht sogar fürdiese Größen kontraproduktiv ist.Allgemein wärees unklug, das Referenzdatenmodell 94d für jedenEinsatzfall in einem Unternehmen zu ändern, da dies ein Umkonfigurierenaller Schnittstellen vom Kern-MDM-Referenzdatenspeicher 132 biszu den lokalen persistenten Speichern 134 der externenoperativen Systeme 40 bedeuten würde. Ein Konstruktionskriteriumfür dieKonfigurationsflexibilitätbesteht darin, dass das Referenzdatenmodell 94d von Einsatzzu Einsatz fest sein sollte und einen übergeordneten Satz erwarteterReferenzdaten 22 fürjedes beliebige Unternehmen darstellen sollte. Das Erreichen diesesZustands kann sich über mehrereEinsätzehin entwickeln, sollte jedoch innerhalb einer relativ kurzen Zeitzu erzielen sein, ohne dass dadurch das Modell beträchtlichumkonstruiert werden muss. Wenn eine Abbildungs-konfiguration ausBenutzersicht notwendig ist, sollte diese vorzugsweise auf der äußerstenKonstruktionsebene durchgeführtwerden (d.h. nahe der Benutzerschnittstelle und nicht im Innernder Datenstrukturen des Kern-MDM-Referenzdatenspeichers 132).
[0116] DerKern-MDM-Referenzdatenspeicher 132 kann riesige Mengenvon Referenzdaten 22 enthalten, insbesondere dann, wenndas MDM-System 4 einem Beispieleinzelhandelsunternehmenzugeordnet ist, das sehr großeZahlen von Artikeln, Standorten oder anderen Entitäten hat.Wenn Attribut/Merkmals-Daten 22e verwendet werden, beidenen mehrere hundert Merkmalsattribute pro Entität durchaus üblich sind,ist das Potential fürriesige Mengen von Referenzdaten 22 sogar noch größer. DieseCharakteristiken könneneffektiv zu sehr hohen Tabellenzeilenzahlen, komplexen relationalenBeziehungen und dem Bedürfnisnach einer Dimensionsstruktur fürdie Referenzdaten 22 führen.Ein Konstruktionskriterium fürdie Skalierbarkeit, das auch sowohl mit dem Durchsatz als auch mitder Abfrageperformance zusammenhängt,ist die Fähigkeitzum effizienten Handhaben großerZeilenmengen, sowohl beim Abfragen der Sätze als auch beim Bewegen derSätze. DieseArt der Effizienz entsteht allgemein aus gut konstruierten und gutabgestimmten relationalen Tabellen, die speziell für performancebezogeneGrößen entworfenwurden. Eine Folge hiervon ist, dass die Konstruktion vorzugsweisezur Verwendung einer parallelen Datenbanktechnik fähig seinsollte, wenn das möglicherweisezur entsprechenden Skalierung in der Unternehmensumgebung nötig seinsollte. Wenn die Konstruktion keine parallele Datenbanktechnik verwendenkann, dann geht die Möglichkeit verloren,die Performance durch eine Einsatzkonfiguration zu steigern.
[0117] Esgibt mehrere Faktoren fürdie Architektur und die Konstruktion einer Benutzerschnittstellefür einMDM-System 4. Ein erster Faktor sind die zwei Typen vonBenutzern des MDM-Systems 4; der Benutzer mit Administratorrolleund der Benutzer in der Rolle eines Prozessteilnehmers. Die ersteKlasse der Benutzerrolle befasst sich hauptsächlich mit der Verwaltung derUnternehmenskonfigurationsinformation, die im MDM-System 4 enthaltenist, sowie den zugeordneten MDM-Modellen 114, die physischin der Datenbank 36 realisiert sind. Die zweite Klasse derBenutzerrolle befasst sich mehr mit dem Sichten und Eingeben vonInformation im Zusammenhang mit Prozessen 14, wie zum Beispieldie Einführung einesneuen Artikels. Eine Schnittstelle in der Art eines Modellierungsstudioskann fürden Benutzer in der Administratorrolle wichtiger sein, während gutgestaltete Ansichts- und Eingabebildschirmsequenzen für den Benutzerin der Prozessteilnehmerrolle wichtiger sein können. Die Benutzerschnittstellenarchitektur-und Konstruktionsanforderungen könnenanhand dieser oder anderer geeigneter Kriterien gegliedert werden.Ein zweiter Faktor ist die Flexibilität, die in der MDM-Architekturinhärentist. In einer Ausführungsformkönnensowohl das Referenzdatenmodell 114d als auch das Aufbereitungsdatenmodell 114e zurZeit des Einsatzes geändertwerden. Dies verleiht dem MDM-System 4 eine Flexibilität zum Eingehen aufdie individuellen Eigenarten des Unternehmens. Dementsprechend gehtdie Benutzerschnittstellenarchitektur vorzugsweise auf diese flexiblenModelle ein. Wenn zum Beispiel ein Feld im Referenzdatenmodell 114d oderim Aufbereitungsdatenmodell 114e hinzugefügt oderentfernt wird, kann ein entsprechender Eingabebildschirm sich demgemäß dynamischauf die Modelländerungeinstellen, ohne dass eine Umprogrammierung notwendig wird.
[0118] 15 zeigt ein Beispiel einerphysischen Architektur 150 für das MDM-System 4,die in loser Weise auf die logische Geschäftsarchitektur 10,die oben anhand von 2 beschriebenwurde, und die logische technische Architektur 30, dieoben anhand von 3 beschriebenwurde, abgebildet werden kann.
[0119] Ineiner Ausführungsformenthältdas MDM-System 4 einen Webserver 152, eine MDM-Anwendungsserverschicht 154,eine Infrastruktur-Dienst-Anwendungsserverschicht 156 undeine MDM-Datenbankschicht 158. Unter der Verwendung einesWebbrowsers oder anders kann ein dem MDM-System 4 zugeordneterBenutzer eine http- (Hypertext Transport Protocol) oder andere Anfrage anden Webserver 152 senden, um den entsprechenden Vorgangdurchzuführen.Der Webserver 152 kann die Anfrage an einen oder mehrereentsprechende Anwendungsserver in der Anwendungsserverschicht 154 weiterleiten,um eine oder mehrere geeignete Anwendungen 160 aufzurufen.Die Anwendungsserverschicht 154 kann einen oder mehrereAnwendungsserver beinhalten, die Maschinen 170a unterstützen, welcheProzess- und Dienstfunktionen des MDM-Systems 4 liefern,die die MDM-Benutzerschnittstelle 140b unterstützen unddie andere geeignete Anwendungen 140 unterstützen. DieInfrastruktur-Dienst-Anwendungsserverschicht 156 kann eineoder mehrere Anwendungsserver enthalten, die front side -Datenzugriffsschicht 42a,die back side – Datenzugriffsschicht 42b undeinen geeigneten Arbeitsablaufcontroller 142 auf Unternehmensebene unterstützen, derProzess- und Dienstfunktionen, die der Datenzugriffsschicht 42 zugeordnetsind, liefert. Zum Beispiel kann in einer bestimmten Ausführungsformdie front side – Datenzugriffsschicht 42a unter Verwendungeines WEBMETHODS ENTERPRISE SERVER – Produkts, die back side – Datenzugriffsschicht 42b teilweiseunter der Verwendung eines INFORMATICA POWERCENTER – Produktsmit einem integrierten Extract-Transform-Load (ETL) – Werkzeugund der Unternehmensebenen-Arbeitsablaufcontroller 142 aufUnternehmensebene unter der Verwendung eines WEBMETHODS BUSINESSINTEGRATOR – Produktsimplementiert werden.
[0120] Ineiner Ausführungsformkann die Implementierung der Prozesse 14 zwischen der Arbeitsablaufmaschine 162 aufUnternehmensebeneder Anwendungsserverschicht 156 und denAnwendungen 160 der Anwendungsserverschicht 154 geteiltwerden. Die Dienste 12 und zugeordnete Dienste 34 können hauptsächlich unterder Verwendung der Anwendungsserverschicht 154 bereitgestelltwerden. Die Datenbankschicht 158 enthält die tatsächlichen physischen Datenmodelle 114,wie zum Beispiel das Referenzdatenmodell 114d und das Aufbereitungsdatenmodell 114e,die oben anhand von 7 beschriebenwurden, mit zugeordneten Datendiensten, die entweder auf der Datenbankschicht 158 oderauf der Anwendungsserverschicht 154 bereitgestellt werden.
[0121] 16 veranschaulicht ein Beispielfür den imMDM-System 4 vorgesehenen Vorgang 14 der Einführung einesneuen Artikels. Auch wenn die Einführung einer neuen Artikelentität für ein Einzelhandelsunternehmenund zugeordnete Zuliefererunternehmen als ein Beispiel beschriebenist, wird bei der vorliegenden Erfindung eine analoge oder auchandere Einführungeiner beliebigen geeigneten neuen Identität für ein beliebiges geeignetesUnternehmen in Betracht gezogen, ob dies hier ausdrücklich beschriebenist oder nicht.
[0122] DieEinführungeines neuen Artikels kommt sehr häufig vor und ist in der Praxisein integraler Bestandteil zwischen dynamischen Wertkettenpartnern, wiezum Beispiel Einzelhändlernund Zulieferern von Fertigerzeugnissen. Die Frequenz neu eingeführter Artikelin das Sortiment eines Einzelhändlerskann von eins bis eintausend je Woche variieren, je nach der Einzelhandelssparteund anderen Faktoren. Die Einführungeines neuen Artikels kann die wichtigste Phase im Lebenszyklus einesArtikels sein. Dieser Vorgang benötigte herkömmlicherweise sehr viel Papierund hemmte die Fähigkeitder Einzelhändlerund Zulieferer, Artikel dynamisch (von einem Tag auf den anderen)einzuführen,da es Tausende von Variablen, Attributen und anderen Faktoren gibt,die bei der Einführungeines neuen Artikels in die Regale des Einzelhändlers berücksichtigt werden müssen, von derPreisgestaltung zur Ausführungauf Regalebene. Es besteht ein geschäftsmäßiger Bedarf bei Einzelhändlern zumAutomatisieren beträchtlicherTeile des Vorgangs zur Einführungeines neuen Artikels und zur Rationalisierung einer Integrationin die Planungs-, Ausführungs-, Überwachungs-und anderen Unternehmenskomponentenlösungen, um neue Artikel inkürzererZeit in den Markt einzuführen,das Kundeninteresse zu wecken und einen Marktanteil zu gewinnen.In einer Ausführungsformenthältdas MDM-System 4 beim Vorgang 14 der Einführung einesneuen Artikels einen eingebetteten Geschäftsarbeitsablauf für die Einführung desneuen Artikels, die es einem Beispieleinzelhandelsunternehmen ermöglichen,einen neuen Artikel schneller, leichter, mit mehr Flexibilität und miteiner größeren Rationalisierungder Integration in Planungs-, Ausführungs-, Überwachungs- oder andere Unternehmenslösungskomponenten 6 alsmit vorhergehenden Verfahren einzuführen.
[0123] Einneuer Artikel kann auf vielerlei Weise eingeführt werden. Zum Beispiel kannein Zulieferer den neuen Artikel bei einem Einzelhändler einführen, ein Einzelhändler kannden neuen Artikel durch die Gestaltung des Artikels einführen (d.h.für einhauseigenes Label), oder ein Einzelhändler und ein Zulieferer können zusammendie Einführungdes neuen Artikels beschließen.Auch wenn bei diesen drei Verfahren der Einführung eines neuen Artikelsgeringe Abweichungen auftreten können,behandelt die vorliegende Beschreibung, da dieses Beispiel sichauf die inneren Arbeitsabläufeeines Einzelhändlerskonzentriert, die Einzelheiten der Einführung eines neuen Artikelsaus einer generischen Sicht. Das heißt, dass die beschriebenenArbeitsabläufedahingehend generisch sind, dass sie diejenigen Prozesse schildern, dieder Einzelhändlerausführenmuss, unabhängig davon,ob der Einzelhändlerden neuen Artikel einführt,der Zulieferer den neuen Artikel einführt oder ob der Einzelhändler undder Zulieferer den neuen Artikel zusammen einführen. Diese Arbeitsabläufe können über alleHändlerformatehinweg (z.B. Großhändler, Kaufhaususw.) und alle Warenklassen hinweg (Hardlines (Konsumartikel ohneKleidung und Wäsche),Nahrungsmittel, Softlines (Kleidung und Wäsche) usw.) anwendbar sein.
[0124] Wiein 16 gezeigt, gibtes in einer Ausführungsformzwei Hauptaspekte des Einführungsvorgangs 14 neuerArtikel: (1) einen ersten Unterprozess 170, der die Einführung, Prüfung, Annahmeund Ablehnung des neuen Artikels beinhaltet, was als analog zurEmpfängniseines Kindes betrachtet werden kann; und (2) ein zweiter Unterprozess 172,bei dem der neue Artikel beim Einzelhändler angelegt wird, um beimneuen Artikel verschiedene Werbe-, Nachbestellungs- und Lieferketten-Planungs-und – Ausführungsfunktionenanzustoßen,um den Artikel im Regal zum Verkauf an den Kunden bereitzustellen,was als analog zur Geburt des Kindes betrachtet werden kann. Dererste Unterprozess 170 kann Folgendes, ohne Einschränkung, enthalten:eine Zulieferereinführungskomponente 174 (beider der Zulieferer den neuen Artikel einführt), eine Einzelhändler-Überprüfungskomponente 176;eine Einzelhändler-Verwerfungs/Modifikations-Komponente 178; eineEinzelhändler-Zustimmungskomponente 180; undeine Zulieferer/Einzelhändler-Vertrags-Finalisierungskomponente 182.Der zweite Unterprozess 172 kann eine Zulieferer/Einzelhändler-Eingabekomponente 184 enthalten,in der der Zulieferer oder Einzelhändler einen oder mehrere entsprechendeMaster fürden neuen Artikel in der Datenbank 36 anlegt. Solche Masterkönnenzum Beispiel Artikelmaster 186, Artikel-Standort-Master 188 undZulieferer-Artikel-Master 190 sein. Nach dem Anlegen undder Speicherung der Master fürden neuen Artikel gemäß der Ausführung derZulieferer/Einzelhändler-Eingabekomponente 184 können Altsysteme 192 undzugeordnete Produktionsdatenbanken 194 des Einzelhändlers oderdes Zulieferers den neuen Artikel für Werbe-, Nachbestellungs-und Lieferketten-Planungs- und -Ausführungs-funktionen empfangenund erkennen.
[0125] DasVorsehen ganz oder teilweise automatisierter Prozesse 14 für die Einführung, denEintrag, die Schaffung und die Pflege neuer Artikel kann viele potentielleVorteile haben. Zum Beispiel kann die Automation des Vorgangs derEinführungeines neuen Artikels einen oder mehrere der folgenden Vorteile, ohneEinschränkung,bieten: (1) Es wird dem Einzelhändlerdie Möglichkeitgegeben, einen neuen Artikel schneller zu bewerben und in sein Sortimentaufzunehmen, wodurch er schneller als seine Mitbewerber den neuenArtikel den Kunden zum Verkauf anbieten kann; (2) als ein Ergebnisder kürzerenMarkteinführungszeitneuer Artikel kann der Einzelhändlerseine Chancen zur Erhöhungder Verkäufeund des Marktanteils beträchtlichverbessern; (3) verringerte Arbeitskosten und geringerer Papierverbrauchinnerhalb verschiedener Einzelhandelsfunktionen und über diesehinweg; (4) Verringerung oder Eliminierung der Möglichkeit von Eingabefehlern,wodurch die Gefahr menschlichen Versagens verringert wird; (5) dasVorsehen einer strafferen und rationalisierterenIntegration desVorgangs der Einführungeines neuen Artikels in Planungs-, Ausführungs-, Überwachungs- oder andere Unternehmenslösungskomponenten 6,was zu einer besseren Platzierung und Nachbestellung der Ware führt; und(6) die Erhöhungendes Wirkungsgrads bei der Planung und Ausführung, die durch die rationalisierteIntegration der Einführungdes neuen Artikels erreicht wurde, kann effektiv genutzt werden,um den Endkunden von den niedrigstmöglichen Kosten durch das Bringender Waren bis ins Regal profitieren zu lassen. Bezüglich derstrafferen und rationalisierteren Integration können Beispiele, ohne Einschränkung, dieFolgenden sein: (1) Daten aus dem Angebot eines Zulieferers im Zusammenhangmit einem neuen Artikel könnenautomatisch fürden Einzelhändlerausgefülltwerden, wodurch sie nicht mehr manuell eingeben werden müssen, umden Vertrag im Zusammenhang mit dem neuen Artikel zu finalisieren;(2) eine Universal Product Code (UPC) – Nummer kann automatisch für einenneuen Artikel geschaffen werden, nachdem der neue Artikel angelegtwurde, wodurch sie nicht mehr manuell eingegeben werden muss; (3)ein Altsystem eines Einzelhändlerskann automatisch überprüft werden,um nachzuprüfen,dass eine UPC-Nummer füreinen neuen Artikel einer Einzelhändler-Produktnummer zugeordnetist, wodurch dieses nicht mehr manuell verifiziert werden muss;und (4) im Zusammenhang mit einem Warenplanungssystem oder anderenUnternehmenslösungskomponenten 6 kann eineProduktnummer fürein neues Produkt automatisch ausgefüllt werden, um ein Produktsortimentunter Einbeziehung eines neuen Artikels zu schaffen, wodurch diesnicht längermanuell eingegeben werden muss.
[0126] Derin 16 dargestellte Einführungsvorgang 14 einesneuen Artikels kann von der Einführungdes neuen Artikels durch den Zulieferer bis zur Pflege des Artikelsdurch den Einzelhändlerin seinen Systemen detaillierter beschrieben werden. In einer Ausführungsformkann die Einführungeines neuen Artikels, die Eingabe, Schaffung und Pflege in Zusammenhangmit dem Einführungsvorgang 14 des neuenArtikels bei einem Beispieleinzelhändler in die folgenden primären Unterprozesse,ohne Einschränkung,aufgegliedert werden: (1) einen Initiierungsunterprozess; (2) einenvorläufigenPlanungsunterprozess; (3) einen Unterprozess für den Artikeleintrag, die Genehmigung,eine anfänglicheVorhersageschätzung,und eine Einleitung der Nach-bestellung; (4) einen Unterprozessfür dieEinrichtung, Schaffung, Aktivierung und anfängliche Nachbestellung einesArtikels; (5) einen Unterprozess für die Bewerbung und die Regalausführung einesArtikels; (6) einen Unterprozess für einen Vorhersageeintrag und eineNachbestellung des Artikels; (7) einen Bestellungsverwaltungs- undZusammenarbeitsunterprozess; (8) Eingangs-(Zulieferer-zu-Einzelhändler) und Ausgangs-(Einzelhändler-zu-Standort)-Lieferkettenplanungs-und -ausführungs-Unterprozesse;(9) einen Artikelpflegeunterprozess; und (10) einen Ausnahmehandhabungs-und Verwaltungs-Unterprozess.
[0127] Auchwenn die vorliegende Erfindung mit mehreren Ausführungsformen beschrieben wurde, kanneinem Fachmann auf diesem Gebiet eine Vielzahl von Veränderungen,Ersetzungen, Variationen, Abänderungenund Modifikationen nahe gelegt werden, und es ist beabsichtigt,dass die Erfindung alle diese Änderungen,Ersetzun-gen, Variationen, Abänderungenund Modifikationen beinhaltet, die in den Geist und Umfang der beiliegendenAnsprüchefallen.

权利要求:
Claims (58)
[1] System zum Verwalten eines zentral verwaltetenMasterspeichers füreinem Unternehmen zugeordnete Kernunternehmensreferenzdaten, aufweisend: – einendie Kernunternehmensreferenzdaten enthaltenden zentralen Masterspeicher,wobei die Kernunternehmensreferenzdaten einer Vielzahl von Datenschematazugeordnet sind, wobei jedes Datenschema ein oder mehrere Datenmodellefür dieKernunternehmensreferenzdaten aufweist, wobei jedes Datenmodellein oder mehrere Felder aufweist; und – eine Datenverwaltungs-Dienststruktur,die mit dem zentralen Masterspeicher verbunden ist und Dienste zumVerwalten der Kernunternehmensreferenzdaten im zentralen Masterspeicherbereitstellt, wobei die Dienststruktur unterstützt: – ein Masterdatenschema, daseine Vereinigung der Vielzahl von Datenmodellen und zugeordnetenFelder in der Vielzahl von Datenschemata aufweist; und – einenDatenthesaurus, der fürjedes Feld im Masterdatenschema einen Satz von Feldsynonymen aufweist,von denen jedes eine Abbildung zwischen dem Feld im Masterdatenschemaund einem entsprechenden Feld in einem Bestimmten aus der Vielzahl vonDatenschemata repräsentiert; – wobeidas Masterdatenschema und der Datenthesaurus eine Zentralverwaltungder Kernunternehmensreferenzdaten im zentralen Masterspeicher über eineVielzahl von heterogenen externen operativen Systemen hinweg ermöglichen,die unterschiedliche zugeordnete Datenmodelle haben und einen indirektenZugang zu den Kernunternehmensreferenzdaten im zentralen Masterspeicherzur operativen Verwendung der Kernunternehmensreferenzdaten gemäß zugeordneterGeschäfts-Arbeitsabläufe erhalten.
[2] System nach Anspruch 1, wobei die Dienststruktureine Benutzerschnittstelle unterstützt, die in der Lage ist, demBenutzer zu erlauben: – eineVielzahl von Datenschemata zu laden, für welche Feldsynonyme und zugeordneteAbbildungen zu erzeugen sind; und – für jedes Feld im Masterdatenschema,für welches einentsprechendes Feld in einem aus der Vielzahol von Datenschemataexistiert, einen Satz von Feldsynonymen und entsprechenden Abbildungenzwischen dem Feld im Masterdatenschema und den entsprechenden Feldernin der Vielzahl von Datenschemata zu erzeugen.
[3] System nach Anspruch 2, wobei die Benutzerschnittstellein der Lage ist, den Datenthesaurus bezüglich des Masterdatenschemasanzuzeigen, wobei alle Felder im Masterdatenschema und ihre entsprechendenFeldsynonyme in der Vielzahl von Datenschemata gezeigt werden.
[4] System nach Anspruch 2, wobei die Benutzerschnittstellein der Lage ist, den Datenthesaurus bezüglich eines bestimmten ausder Vielzahl von Datenschemata, das als Hauptdatenschema bezeichnet wird,anzuzeigen, wobei alle Felder im Hauptdatenschema und ihre entsprechendenFeldsynonyme in einem oder mehreren anderen Datenschemata gezeigtwerden.
[5] System nach Anspruch 4, wobei das Hauptdatenschemaein benutzerspezifiziertes Hauptdatenschema aufweist.
[6] System nach Anspruch 4, wobei das eine oder die mehrerenanderen Datenschemata alle anderen Datenschemata aufweisen.
[7] System nach Anspruch 4, wobei das eine oder die mehrerenanderen Datenschemata ein benutzerspezifiziertes Datenschema aufweisen.
[8] System nach Anspruch 1, wobei das Masterdatenschemaein Masterdatenmodell überdie Vielzahl von Datenschemata hinweg aufweist.
[9] System nach Anspruch 1, wobei das Masterdatenschemaund der Datenthesaurus die Modifikation eines externen operativenSystems ermöglichen, ohnedass dafürdas Modifizieren des dem externen operativen System zugeordnetenDatenmodells nötig wird.
[10] System nach Anspruch 1, wobei ein Datenmodell Metadatenaufweist, welche die Kernunternehmensreferenzdaten im zentralenMasterspeicher beschreiben.
[11] System nach Anspruch 1, wobei die Dienststruktureine Benutzerschnittstelle unterstützt, die in der Lage ist, eseinem Benutzer zu erlauben, ein Basisdatenmodell im Kontext desEntsprechenden aus der Vielzahl von Schemata dadurch zu erweitern, dassden schon im Basisdatenmodell vorhandenen Basisfeldern neue Erweiterungsfelderhinzugefügt werden,wobei die bestehenden physischen Tabellenstrukturen für das Basisdatenmodellfür daserweiterte Datenmodell erhalten bleiben.
[12] System nach Anspruch 1, wobei die Dienststruktureine Benutzerschnittstelle unterstützt, die in der Lage ist, eseinem Benutzer zu erlauben, ein Basisdatenmodell im Kontext desEntsprechenden aus der Vielzahl von Schemata dadurch zu erweitern, dassein neues erweitertes Datenmodell erzeugt wird, das alle Basisfeldervom Basisdatenmodell erbt, wobei neue physische Tabellenstrukturenfür daserweiterte Datenmodell erzeugt werden, um bestehende physische Tabellenstrukturenfür dasBasisdatenmodell zu ersetzen.
[13] System nach Anspruch 1, wobei: – die Dienststrukturunterstützt: – ein Masterdatenverzeichnisfür dasMasterschema, das eine Liste aller Felder im Masterdatenschema aufweist; – ein Datenverzeichnisfür jedesaus der Vielzahl von Datenschemata, wobei jedes Datenverzeichniseine Liste aller Felder in dem entsprechenden Bestimmten aus derVielzahl von Datenschemata aufweist; und – der Datenthesaurus für jedesFeld im Masterdatenverzeichnis fürdas Masterdatenschema einen Satz von Feldsynonymen aufweist, vondenen jedes eine Abbildung zwischen dem Feld im Masterdatenverzeichnisund einem Feld im Datenverzeichnis für ein Bestimmtes aus der Vielzahlvon Datenschemata repräsentiert.
[14] System nach Anspruch 13, wobei die Dienststruktureine Benutzerschnittstelle unterstützt, die in der Lage ist, dasMasterdatenverzeichnis in einem oder mehreren der folgenden Formateanzuzeigen; – alphabetischnach Feldname, wobei fürjedes Feld eine Liste von Datenmodellen, in denen das Feld enthaltenist, alphabetisch nach Datenmodellname in Verbindung mit dem Feldnamenangezeigt wird; und – alphabetischnach Datenmodellname, wobei fürjedes Datenmodell eine Liste von Feldern innerhalb des Datenmodellsalphabetisch nach Feldname in Verbindung mit dem Datenmodellnamenangezeigt wird.
[15] System nach Anspruch 13, wobei die Dienststrukturin der Lage ist, das Masterdatenlexikon als Basis zur Erzeugungeines neuen Datenmodells, das ein oder mehrere neue Felder aufweist,zu verwenden, wobei entweder: – zuerst das Masterdatenverzeichnismit den neuen Feldern aktualisiert wird und dann das neue Datenmodellauf der Grundlage des aktualisierten Masterdatenverzeichnis erzeugtwird; oder – zuerstdas die neuen Felder aufweisende neue Datenmodell erzeugt und danndas Masterdatenverzeichnis gemäß dem neuenDatenmodell aktualisiert wird.
[16] System nach Anspruch 15, wobei, wenn zuerst dasdie neuen Felder aufweisende neue Datenmodell erzeugt wird, dasaktualisierte Masterdatenverzeichnis dann automatisch gemäß dem neuen Datenmodellgeneriert wird.
[17] System nach Anspruch 1, wobei: – die Kernunternehmensreferenzdateneiner Vielzahl von Datendomänenin jedem aus der Vielzahl von Datenschemata zugeordnet sind, wobeijede Datendomäneein oder mehrere Felder aufweist; und – der Datenthesaurus für jedesFeld in einem bestimmten Datenschema einen Satz von Feldsynonymenaufweist, von denen jedes eine Abbildung zwischen dem Feld in dembestimmten Datenschema und einem Feld in einem Bestimmten aus derVielzahl von Datendomänenrepräsentiert.
[18] System nach Anspruch 17, wobei die Dienststruktureine Benutzerschnittstelle unterstützt, die in der Lage ist, denDatenthesaurus bezüglicheiner Bestimmten aus der Vielzahl von Datendomänen, die als Hauptdatendomäne bezeichnetwird, anzuzeigen, wobei alle Felder in der Hauptdatendomäne und ihre entsprechendenFeldsynonyme in einer oder mehreren anderen Datendomänen gezeigtwerden.
[19] System nach Anspruch 17, wobei die Dienststrukturunterstützt: – ein Datenverzeichnisfür jedesaus der Vielzahl von Datenschemata, wobei jedes Datenverzeichniseine Liste aller Felder in dem entsprechenden Bestimmten aus derVielzahl von Datenschemata aufweist; und – eine Benutzerschnittstelle,die in der Lage ist, es einem Benutzer zu erlauben, Felder einerbestimmten Datendomäneunter der Verwendung eines oder mehrerer der folgenden Verfahrenzuzuweisen: – Hinzufügen derFelder zu einem Datenmodell zum Erweitern des Datenmodells, Hinzufügen derFelder zum Datenverzeichnis fürein der bestimmten Datendomänezugeordnetes Datenschema zum Aktualisieren des Datenverzeichnissesund Einstellen der bestimmten Datendomäne für die Felder zum Zuweisen derFelder zur bestimmten Datendomäne; – Erzeugeneines die Felder aufweisenden neuen Datenmodells, Hinzufügen derFelder zum Datenverzeichnis fürein der bestimmten Datendomänezugeordnetes Datenschema zum Aktualisieren des Datenverzeichnissesund Einstellen der bestimmten Datendomäne für die Felder zum Zuweisen derFelder zur bestimmten Datendomäne;und – Eingebeneines Namens fürdie bestimmte Datendomäne,Hinzufügender Felder in das Datenverzeichnis für ein der bestimmten Datendomäne zugeordnetesDatenschema zum Aktualisieren des Datenverzeichnisses, Erzeugeneines neuen Datenmodells unter der Verwendung des aktualisiertenDatenverzeichnisses und Hinzufügender Felder zum neuen Datenmodell zum Zuweisen der Felder zur bestimmtenDatendomäne.
[20] Verfahren zum Verwalten eines zentral verwaltetenMasterspeichers füreinem Unternehmen zugeordnete Kernunternehmensreferenzdaten aufweisend: – Verwendeneines zentralen Masterspeichers zum Speichern der Kernunternehmensreferenzdaten,wobei die Kernunternehmensreferenzdaten einer Vielzahl von Datenschematazugeordnet sind, wobei jedes Datenschema ein oder mehrere Datenmodelle für Kernunternehmensreferenzdatenaufweist, wobei jedes Datenmodell ein oder mehrere Felder aufweist; und – Verwendeneiner Datenverwaltungs-Dienststruktur, die mit dem zentralen Masterspeicherverbunden ist und die Dienste zum Verwalten der Kernunternehmensreferenzdatenim zentralen Masterspeicher bereitstellt, wobei die Dienststrukturunterstützt: – ein Masterdatenschema,das eine Vereinigung der Vielzahl von Datenmodellen und zugeordnetenFeldern in der Vielzahl von Datenschemata aufweist; und – einenDatenthesaurus, der fürjedes Feld im Masterdatenschema einen Satz von Feldsynonymen aufweist,von denen jedes eine Abbildung zwischen dem Feld im Masterdatenschemaund einem entsprechenden Feld in einem Bestimmten aus der Vielzahl vonDatenschemata repräsentiert; – wobeidas Masterdatenschema und der Datenthesaurus eine Zentralverwaltungder Kernunternehmensreferenzdaten im zentralen Masterspeicher über eineVielzahl von heterogenen externen operativen Systemen hinweg ermöglichen,die unterschiedliche zugeordnete Datenmodelle haben und einen indirektenZugang zu den Kernunternehmensreferenzdaten im zentralen Masterspeicherzur operativen Verwendung der Kernunternehmensreferenzdaten gemäß zugeordneterGeschäfts-Arbeitsabläufe erhalten.
[21] Verfahren nach Anspruch 20, weiter aufweisend dasVerwenden einer der Dienststruktur zugeordneten Benutzerschnittstelle,um: – eineVielzahl von Datenschemata zu laden, für welche Feldsynonyme und zugeordneteAbbildungen zu erzeugen sind; und – für jedes Feld im Masterdatenschema,für welches einentsprechendes Feld in einem aus der Vielzahl von Datenschemataexistiert, einen Satz von Feldsynonymen und entsprechenden Abbildungenzwischen dem Feld im Masterdatenschema und den entsprechenden Feldernin der Vielzahl von Datenschemata zu erzeugen.
[22] Verfahren nach Anspruch 21, weiter aufweisend dasVerwenden der Benutzerschnittstelle, um den Datenthesaurus bezüglich desMasterdatenschemas anzuzeigen, wobei alle Felder im Masterdatenschemaund ihre entsprechenden Feldsynonyme in der Vielzahl von Datenschematagezeigt werden.
[23] Verfahren nach Anspruch 21, weiter aufweisend dasVerwenden der Benutzerschnittstelle, um den Datenthesaurus bezüglich einesBestimmten aus der Vielzahl von Datenschemata, das als Hauptdatenschemabezeichnet wird, anzuzeigen, wobei alle Felder im Hauptdatenschemaund ihre entsprechenden Feldsynonyme in einem oder mehreren anderenDatenschemata angezeigt werden.
[24] Verfahren nach Anspruch 23, wobei das Hauptdatenschemaein benutzerspezifiziertes Hauptdatenschema umfasst.
[25] Verfahren nach Anspruch 23, wobei das eine oderdie mehreren anderen Datenschemata alle anderen Datenschemata aufweisen.
[26] Verfahren nach Anspruch 23, wobei das eine oderdie mehreren anderen Datenschemata ein benutzerspezifiziertes Datenschemaaufweisen.
[27] Verfahren nach Anspruch 20, wobei das Masterdatenschemaein Masterdatenmodell überdie Vielzahl von Datenschemata hinweg aufweist.
[28] Verfahren nach Anspruch 20, wobei das Masterdatenschemaund der Datenthesaurus die Modifikation eines externen operativenSystems ermöglichen,ohne dass dafürdas Modifizieren des dem externen operativen System zugeordnetenDatenmodells nötigwird.
[29] Verfahren nach Anspruch 20, wobei ein DatenmodellMetadaten aufweist, welche die Kernunternehmensreferenzdaten imzentralen Masterspeicher beschreiben.
[30] Verfahren nach Anspruch 20, weiter aufweisend dasVerwenden einer der Dienststruktur zugeordneten Benutzerschnittstellezum Erweitern eines Basisdatenmodells im Kontext des Entsprechenden ausder Vielzahl von Schemata dadurch, dass den schon im Basisdatenmodellvorhandenen Basisfeldern neue Erweiterungsfelder hinzugefügt werden, wobeidie bestehenden physischen Tabellenstrukturen für das Basisdatenmodell für das erweiterteDatenmodell erhalten bleiben.
[31] Verfahren nach Anspruch 20, weiter aufweisend dasVerwenden einer der Dienststruktur zugeordneten Benutzerschnittstellezum Erweitern eines Basisdatenmodells im Kontext des Entsprechenden ausder Vielzahl von Schemata, dadurch, dass ein neues erweitertes Datenmodellerzeugt wird, das alle Basisfelder vom Basisdatenmodell erbt, wobeineue physische Tabellenstrukturen für das erweiterte Datenmodellerzeugt werden, um bestehende physische Tabellenstrukturen für das Basisdatenmodellzu ersetzen.
[32] Verfahren nach Anspruch 20, wobei: – die Dienststrukturunterstützt: – ein Masterdatenverzeichnisfür dasMasterschema, das eine Liste aller Felder im Masterdatenschema aufweist; – ein Datenverzeichnisfür jedesaus der Vielzahl von Datenschemata, wobei jedes Datenverzeichniseine Liste aller Felder in dem entsprechenden Bestimmten aus derVielzahl von Datenschemata aufweist; und – der Datenthesaurus für jedesFeld im Masterdatenverzeichnis fürdas Masterdatenschema einen Satz von Feldsynonymen aufweist, vondenen jedes eine Abbildung zwischen dem Feld im Masterdatenverzeichnisund einem Feld im Datenverzeichnis für ein Bestimmtes aus der Vielzahlvon Datenschemata repräsentiert.
[33] Verfahren nach Anspruch 32, weiter aufweisend dasVerwenden einer der Dienststruktur zugeordneten Benutzerschnittstellezum Anzeigen des Masterdatenverzeichnisses in einem oder mehreren derfolgenden Formate: – alphabetischnach Feldname, wobei fürjedes Feld eine Liste von Datenmodellen, in denen das Feld enthaltenist, alphabetisch nach Datenmodellname in Verbindung mit dem Feldnamenangezeigt wird; und – alphabetischnach Datenmodellname, wobei fürjedes Datenmodell eine Liste von Feldern innerhalb des angezeigtenDatenmodells alphabetisch nach Feldname in Verbindung mit dem Datenmodellnamenangezeigt wird.
[34] Verfahren nach Anspruch 32, weiter aufweisend dasVerwenden des Masterdatenverzeichnisses als Basis zum Erzeugen einesneuen Datenmodells, das ein oder mehrere neue Felder aufweist, wobeientweder: – zuerstdas Masterdatenverzeichnis mit den neuen Feldern aktualisiert wirdund dann das neue Datenmodell auf der Grundlage des aktualisiertenMasterdatenverzeichnisses erzeugt wird; oder – zuerstdas die neuen Felder aufweisende neue Datenmodell erzeugt und danndas Masterdatenverzeichnis gemäß dem neuenDatenmodell aktualisiert wird.
[35] Verfahren nach Anspruch 34, wobei, wenn zuerst dasdie neuen Felder aufweisende neue Datenmodell erzeugt wird, dasaktualisierte Masterdatenverzeichnis dann automatisch gemäß dem neuen Datenmodellgeneriert wird.
[36] Verfahren nach Anspruch 20, wobei: – die Kernunternehmensreferenzdateneiner Vielzahl von Datendomänenin jedem aus der Vielzahl von Datenschemata zugeordnet sind, wobeijede Datendomäneeines oder mehrere Felder aufweist; und – der Datenthesaurus für jedesFeld in einem bestimmten Datenschema einen Satz von Feldsynonymenaufweist, von denen jedes eine Abbildung zwischen dem Feld in dembestimmten Datenschema und einem Feld in einem Bestimmten aus derVielzahl von Datendomänenrepräsentiert.
[37] Verfahren nach Anspruch 36, weiter aufweisend dasVerwenden einer der Dienststruktur zugeordneten Benutzerschnittstellezum Anzeigen des Datenthesaurus bezüglich einer Bestimmten ausder Vielzahl von Datendomänen,die als Hauptdatendomänebezeichnet wird, wobei alle Felder in der Hauptdatendomäne und ihreentsprechenden Feldsynonyme in einer oder mehreren anderen Datendomänen gezeigtwerden.
[38] Verfahren nach Anspruch 36, wobei: – die Dienststrukturein Datenverzeichnis fürjedes aus der Vielzahl von Datenschemata unterstützt, wobei jedes Datenverzeichniseine Liste aller Felder im entsprechenden Bestimmten aus der Vielzahlvon Datenschemata aufweist; und – das Verfahren weiter dasVerwenden einer der Dienststruktur zugeordneten Benutzerschnittstelle aufweist,um Felder zu einer bestimmten Datendomäne unter der Verwendung einesoder mehrerer der folgenden Verfahren zuzuweisen: – Hinzufügen derFelder zu einem Datenmodell zum Erweitern des Datenmodells, Hinzufügen derFelder zum Datenverzeichnis fürein der bestimmten Datendomänezugeordnetes Datenschema zum Aktualisieren des Datenverzeichnissesund Einstellen der bestimmten Datendomäne für die Felder zum Zuweisen derFelder zur bestimmten Datendomäne; – Erzeugeneines die Felder aufweisenden neuen Datenmodells, Hinzufügen derFelder in das Datenverzeichnis fürein der bestimmten Datendomänezugeordnetes Datenschema zum Aktualisieren des Datenverzeichnissesund Einstellen der bestimmten Datendomäne für die Felder zum Zuweisen derFelder zur bestimmten Datendomäne;und – Eingebeneines Namens fürdie bestimmte Datendomäne,Hinzufügender Felder in das Datenverzeichnis für ein der bestimmten Datendomäne zugeordnetesDatenschema zum Aktualisieren des Datenverzeichnisses, Erzeugeneines neuen Datenmodells unter Verwendung des aktualisierten Datenverzeichnissesund Hinzufügender Felder zum neuen Datenmodell zum Zuweisen der Felder zur bestimmtenDatendomäne.
[39] Software zum Verwalten eines zentral verwaltetenMasterspeichers füreinem Unternehmen zugeordnete Kernunternehmensreferenzdaten, wobeidie Software in einem computerlesbaren Medium vorhanden ist undbei ihrer Ausführungin der Lage ist: – aufeinen zentralen Masterspeicher zum Speichern der Kernunternehmensreferenzdatenzuzugreifen, wobei die Kernunternehmensreferenzdaten einer Vielzahlvon Datenschemata zugeordnet sind, wobei jedes Datenschema einesoder mehrere Datenmodelle fürKernunternehmensreferenzdaten aufweist, wobei jedes Datenmodelleines oder mehrere Felder aufweist; und – eine Datenverwaltungs-Dienststrukturbereitzustellen, die mit dem zentralen Masterspeicher verbunden istund Dienste zum Verwalten der Kernunternehmensreferenzdaten im zentralenMasterspeicher bereitstellt, wobei die Dienststruktur unterstützt: – ein Masterdatenschema,das eine Vereinigung der Vielzahl von Datenmodellen und zugeordnetenFeldern in der Vielzahl von Datenschemata aufweist; und – einenDatenthesaurus, der fürjedes Feld im Masterdatenschema einen Satz von Feldsynonymen aufweist,von denen jedes eine Abbildung zwischen dem Feld im Masterdatenschemaund einem entsprechenden Feld in einem Bestimmten aus der Vielzahl vonDatenschemata repräsentiert; – wobeidas Masterdatenschema und der Datenthesaurus eine Zentralverwaltungder Kernunternehmensreferenzdaten im zentralen Masterspeicher über eineVielzahl von heterogenen externen operativen Systemen hinweg ermöglichen,die unterschiedliche zugeordnete Datenmodelle haben und einen indirektenZugang zu den Kernunternehmensreferenzdaten im zentralen Masterspeicherzur operativen Verwendung der Kernunternehmensreferenzdaten gemäß zugeordneterGeschäfts-Arbeitsabläufe erhalten.
[40] Software nach Anspruch 39, die weiter in der Lageist, eine der Dienststruktur zugeordnete Benutzerschnittstelle bereitzustellen,um: – eineVielzahl von Datenschemata zu laden, für welche Feldsynonyme und zugeordneteAbbildungen zu erzeugen sind; und – für jedes Feld im Masterdatenschema,für welches einentsprechendes Feld in einem aus der Vielzahl von Datenschemataexistiert, einen Satz von Feldsynonymen und entsprechenden Abbildungenzwischen dem Feld im Masterdatenschema und den entsprechenden Feldernin der Vielzahl von Datenschemata zu erzeugen.
[41] Software nach Anspruch 40, die weiter in der Lageist, die Benutzerschnittstelle zum Anzeigen des Datenthesaurus bezüglich demMasterdatenschema zu verwenden, wobei alle Felder im Masterdatenschemaund ihre entsprechenden Feldsynonyme in der Vielzahl von Datenschematagezeigt werden.
[42] Software nach Anspruch 40, die weiter in der Lageist, die Benutzerschnittstelle zum Anzeigen des Datenthesaurus bezüglich einesBestimmten aus der Vielzahl von Datenschemata, das als Hauptdatenschemabezeichnet wird, zu verwenden, wobei alle Felder im Hauptdatenschemaund ihre entsprechenden Feldsynonyme in einem oder mehreren anderen Datenschematagezeigt werden.
[43] Software nach Anspruch 42, wobei das Hauptdatenschemaein benutzerspezifiziertes Hauptdatenschema aufweist.
[44] Software nach Anspruch 42, wobei das eine oder diemehreren anderen Datenschemata alle anderen Datenschemata aufweisen.
[45] Software nach Anspruch 42, wobei das eine oder diemehreren anderen Datenschemata ein benutzerspezifiziertes Datenschemaaufweisen.
[46] Software nach Anspruch 39, wobei das Masterdatenschemaein Masterdatenmodell überdie Vielzahl von Datenschemata hinweg aufweist.
[47] Software nach Anspruch 39, wobei das Masterdatenschemaund der Datenthesaurus die Modifikation eines externen operativenSystems ermöglichen,ohne dass dafürdas Modifizieren des dem externen operativen System zugeordnetenDatenmodells nötigwird.
[48] Software nach Anspruch 39, wobei ein DatenmodellMetadaten aufweist, welche die Kernunternehmensreferenzdaten imzentralen Masterspeicher beschreiben.
[49] Software nach Anspruch 39, die weiter in der Lageist, eine der Dienststruktur zugeordnete Benutzerschnittstelle bereitzustellen,um es einem Benutzer zu erlauben, ein Basisdatenmodell im Kontext desEntsprechenden aus der Vielzahl von Schemata dadurch zu erweitern,dass den schon im Basisdatenmodell vorhandenen Basisfeldern neueErweiterungsfelder hinzugefügtwerden, wobei die bestehenden physischen Tabellenstrukturen für das Basisdatenmodellfür daserweiterte Datenmodell erhalten bleiben.
[50] Software nach Anspruch 39, die weiter in der Lageist, eine der Dienststruktur zugeordnete Benutzerschnittstelle bereitzustellen,um es einem Benutzer zu erlauben, ein Basisdatenmodell im Kontext desEntsprechenden aus der Vielzahl von Schemata dadurch zu erweitern,dass ein neues erweitertes Datenmodell erzeugt wird, das alle Basisfeldervom Basisdatenmodell erbt, wobei neue physische Tabellenstrukturenfür daserweiterte Datenmodell erzeugt werden, um bestehende physische Tabellenstrukturenfür dasBasisdatenmodell zu ersetzen.
[51] Software nach Anspruch 39, wobei: – die Dienststrukturunterstützt: – ein Masterdatenverzeichnisfür dasMasterschema, das eine Liste aller Felder im Masterdatenschema aufweist; – ein Datenverzeichnisfür jedesaus der Vielzahl von Datenschemata, wobei jedes Datenverzeichniseine Liste aller Felder in dem entsprechenden Bestimmten aus derVielzahl von Datenschemata aufweist; und – der Datenthesaurus für jedesFeld im Masterdatenverzeichnis fürdas Masterdatenschema einen Satz von Feldsynonymen aufweist, vondenen jedes eine Abbildung zwischen dem Feld im Masterdatenverzeichnisund einem Feld im Datenverzeichnis für ein Bestimmtes aus der Vielzahlvon Datenschemata repräsentiert.
[52] Software nach Anspruch 51, die weiter dazu in derLage ist, eine der Dienststruktur zugeordnete Benutzerschnittstellezum Anzeigen des Masterdatenverzeichnisses in einem oder mehrerender folgenden Formate bereizustellen: – alphabetisch nach Feldname,wobei fürjedes Feld eine Liste von Datenmodellen, in denen das Feld enthaltenist, alphabetisch nach Datenmodellname in Verbindung mit dem Feldnamenangezeigt wird; und – alphabetischnach Datenmodellname, wobei fürjedes Datenmodell eine Liste von Feldern innerhalb des Datenmodellsalphabetisch nach Feldname in Verbindung mit dem Datenmodellnamenangezeigt wird.
[53] Software nach Anspruch 51, die weiter in der Lageist, das Masterdatenverzeichnis als die Basis zur Erzeugung einesneuen Datenmodells, das ein oder mehrere neue Felder aufweist, wobeientweder: – zuerstdas Masterdatenverzeichnis mit den neuen Feldern aktualisiert wirdund dann das neue Datenmodell auf der Grundlage des aktualisiertenMasterdatenverzeichnisses erzeugt wird; oder – zuerstdas die neuen Felder aufweisende neue Datenmodell erzeugt und danndas Masterdatenverzeichnis gemäß dem neuenDatenmodell aktualisiert wird.
[54] Software nach Anspruch 53, wobei, wenn zuerst dasdie neuen Felder aufweisende neue Datenmodell erzeugt wird, dasaktualisierte Masterdatenverzeichnis dann automatisch gemäß dem neuen Datenmodellerzeugt wird.
[55] Software nach Anspruch 39, wobei: – die Kernunternehmensreferenzdateneiner Vielzahl von Datendomänenin jedem aus der Vielzahl der Datenschemata zugeordnet sind, wobeijede Datendomäneeines oder mehrere Felder aufweist; und – der Datenthesaurus für jedesFeld in einem bestimmten Datenschema einen Satz von Feldsynonymenaufweist, von denen jedes eine Abbildung zwischen dem Feld in dembestimmten Datenschema und einem Feld in einem Bestimmten aus derVielzahl von Datendomänenrepräsentiert.
[56] Software nach Anspruch 55, die weiter in der Lageist, eine der Dienststruktur zugeordnete Benutzerschnittstelle zumAnzeigen des Datenthesaurus bezüglicheiner Bestimmten aus der Vielzahl von Datendomänen, die als Hauptdatendomäne bezeichnet wird,bereitzustellen, wobei alle Felder in der Hauptdatendomäne und ihreentsprechenden Feldsynonyme in einer oder mehreren anderen Datendomänen gezeigtwerden.
[57] Software nach Anspruch 55, wobei – die Dienststrukturein Datenverzeichnis fürjedes aus der Vielzahl von Datenschemata unterstützt, wobei jedes Datenverzeichniseine Liste aller Felder in dem entsprechenden Bestimmten aus derVielzahl von Datenschemata enthält;und – dieSoftware weiter in der Lage ist, eine der Dienststruktur zugeordneteBenutzerschnittstelle bereitzustellen, um es einem Benutzer zu erlauben,Felder zu einer bestimmten Datendomäne unter der Verwendung einesoder mehrerer der folgenden Verfahren zuzuweisen: – Hinzufügen derFelder zu einem Datenmodell zum Erweitern des Datenmodells, Hinzufügen derFelder zum Datenverzeichnis fürein der bestimmten Datendomänezugeordnetes Datenschema zum Aktualisieren des Datenlverzeichnissesund Einstellen der bestimmten Datendomäne für die Felder zum Zuweisen derFelder zur bestimmten Datendomäne; – Erzeugeneines die Felder aufweisenden neuen Datenmodells, Hinzufügen derFelder zum Datenverzeichnis fürein der bestimmten Datendomänezugeordnetes Datenschema zum Aktualisieren des Datenverzeichnissesund Einstellen der bestimmten Datendomäne für die Felder zum Zuweisen derFelder zur bestimmten Datendomäne;und – Eingebeneines Namens fürdie bestimmte Datendomäne,Hinzufügender Felder in das Datenverzeichnis für ein der bestimmten Datendomäne zugeordnetesDatenschema zum Aktualisieren des Datenverzeichnisses, Erzeugeneines neuen Datenmodells unter Verwendung des aktualisierten Datenverzeichnissesund Hinzufügender Felder zum neuen Datenmodell zum Zuweisen der Felder zur bestimmtenDatendomäne.
[58] System zum Verwalten eines zentral verwalteten Masterspeichersfür einemUnternehmen zugeordnete Kernunternehmensreferenzdaten, aufweisend: – ersteMittel zum Bereitstellen eines zentralen Masterspeichers für die Kernunternehmensreferenzdaten,wobei die Kernunternehmensreferenzdaten einer Vielzahl von Datenschematazugeordnet sind, wobei jedes Datenschema eines oder mehrere Datenmodellefür Kernunternehmensreferenzdatenaufweist, wobei jedes Datenmodell eines oder mehrere Felder aufweist;und – zweiteMittel, die mit den ersten Mitteln verbunden sind, zum Bereitstellenvon Diensten zum Verwalten der Kernunternehmensreferenzdaten imzentralen Masterspeicher, wobei die ersten Mittel unterstützen: – ein Masterdatenschema,das eine Vereinigung aus der Vielzahl von Datenmodellen und zugeordneten Felderin der Vielzahl von Datenschemata aufweist; und – einenDatenthesaurus, der fürjedes Feld im Masterdatenschema einen Satz von Feldsynonymen aufweist,von denen jedes eine Abbildung zwischen dem Feld im Masterdatenschemaund einem entsprechenden Feld in einem Bestimmten aus der Vielzahl vonDatenschemata repräsentiert; – wobeidas Masterdatenschema und der Datenthesaurus eine Zentralverwaltungder Kernunternehmensreferenzdaten im zentralen Masterspeicher über eineVielzahl von heterogenne externen operativen Systemen hinweg ermöglichen,die unterschiedliche zugeordnete Datenmodelle haben und einen indirektenZugang zu den Kernunternehmensreferenzdaten im zentralen Masterspeicherzur operativen Verwendung der Kernunternehmensreferenzdaten gemäß zugeordneterGeschäfts-Arbeitsabläufe erhalten.

类似技术:

---

公开号 | 公开日 | 专利标题

---

US10073907B2|2018-09-11|System and method of analyzing and graphically representing transaction items

---

US20180108077A1|2018-04-19|Intelligent Multimedia E-Catalog

---

US10545937B2|2020-01-28|Method and apparatus for converting heterogeneous databases into standardized homogeneous databases

---

Kurbel2016|Enterprise resource planning and supply chain management

---

US10388044B2|2019-08-20|Dimension reducing visual representation method

---

US9632768B2|2017-04-25|Exchanging project-related data in a client-server architecture

---

US20170018102A1|2017-01-19|Data visualization system and method

---

US9218398B2|2015-12-22|Content storage mapping

---

US9292573B2|2016-03-22|Extended database engine providing versioning and embedded analytics

---

US8543603B2|2013-09-24|Visualization of data relationships between components of a project

---

US10783677B2|2020-09-22|System and method of identifying and visually representing adjustable data

---

CN101971165B|2013-07-17|数据关系的图形表示

---

US6581068B1|2003-06-17|System and method for instant consolidation, enrichment, delegation and reporting in a multidimensional database

---

US7716170B2|2010-05-11|Holistic dynamic information management platform for end-users to interact with and share all information categories, including data, functions, and results, in collaborative secure venue

---

US7814470B2|2010-10-12|Multiple service bindings for a real time data integration service

---

US5560005A|1996-09-24|Methods and systems for object-based relational distributed databases

---

US7069514B2|2006-06-27|Modeling system for retrieving and displaying data from multiple sources

---

JP4473245B2|2010-06-02|Ａｕｔｏ−ＩＤデータを可視化するためのシステムおよび方法

---

US6263341B1|2001-07-17|Information repository system and method including data objects and a relationship object

---

DE60311805T2|2007-11-22|Erfassung, Zusammenstellung und/oder Visualisierung von strukturellen Merkmalen von Architekturen

---

TWI222588B|2004-10-21|Customizable state machine and state aggregation technique for processing collaborative and transactional business objects

---

CN101111838B|2011-01-19|多维企业软件系统中的自动关系模式生成

---

CN100465953C|2009-03-04|用逻辑模型查询物理字段或处理抽象查询的方法及系统

---

CN101167048B|2011-01-19|多维企业软件系统内的可聚集维度信息的生成

---

CN103177061B|2017-08-08|分区表中的唯一值估计

同族专利:

---

公开号 | 公开日

---

TW200508910A|2005-03-01|

---

TWI360083B|2012-03-11|

---

US7310646B2|2007-12-18|

---

US20080281824A1|2008-11-13|

---

US20050021541A1|2005-01-27|

---

US8239426B2|2012-08-07|

引用文献:

---

公开号 | 申请日 | 公开日 | 申请人 | 专利标题

---

法律状态:
2008-03-13| 8128| New person/name/address of the agent|Representative=s name: DF-MP, 80333 MUENCHEN |

---

2012-01-19| R082| Change of representative|Representative=s name: DF-MP, DE Representative=s name: DF-MP, 80333 MUENCHEN, DE |

---

2012-05-10| R081| Change of applicant/patentee|Owner name: JDA SOFTWARE GROUP, INC., SCOTTSDALE, US Free format text: FORMER OWNER: I2 TECHNOLOGIES, INC., DALLAS, TEX., US Effective date: 20120119 |

---

2012-05-10| R012| Request for examination validly filed|Effective date: 20110509 |

---

2012-05-10| R082| Change of representative|Representative=s name: DF-MP DOERRIES FRANK-MOLNIA & POHLMAN PATENTAN, DE Effective date: 20120119 |

---

2013-05-21| R016| Response to examination communication|

---

2014-12-02| R119| Application deemed withdrawn, or ip right lapsed, due to non-payment of renewal fee|

---

2015-02-26| R119| Application deemed withdrawn, or ip right lapsed, due to non-payment of renewal fee|Effective date: 20141202 |

优先权:

---

申请号 | 申请日 | 专利标题

---